Add activation of audio context on user events if suspended

[jbphet]

Chrome is adding a feature to block autoplay of audio when a website loads, and that unfortunately prevents sound generation from our simulations. Code has been added to the published sound generation code in the vibe repo that turns sound on once the user interacts with the sim, see phetsims/vibe#32. That same fix needs to be incorporated into the sonification manager.

[jbphet]

I've added the fix, and also improved the handling for activating audio on iOS. This seems to work well, but it's hard to be 100% certain until Chrome adds back autoplay blocking. I tried testing via an incognito window, but the audio context was never suspended in this case. I'm going to leave this issue open but unassigned and deferred, and will add a reminder on my calendar to test again when autoplay blocking reappears in Chrome Canary.

[jbphet]

There is some important information on this issue in phetsims/vibe#32 (comment) and phetsims/vibe#32 (comment).

[jbphet]

Chrome has added autoplay blocking in version 71, which is live as of this writing. They added it in a smart way - basically, sound generation is initially blocked but is unblocked automatically once the user interacts with the web page. This seems to work reasonably well for our purposes, though I have noticed some cases where if the very first thing the user does causes a sound, the sound kind of fades in rather than starts strong (for an example, load the sonified version of the friction sim and grab the magnified book as the first interaction). This would seem to imply that the workaround code isn't needed, but I'm going to leave it there anyway in case the policy changes.

There is more information on this at the GitHub issue linked in the previous comment.

For the foreseeable future, there isn't anything to do on this issue, so I'm going to close it.

[jbphet]

I'm going to reopen this and do some more work on the issue. As I learn more about it, it's making me think that adding some better handling of this will improve the sonic portion of the user experience.

[jbphet]

EDIT (6/3/2019): The information below isn't quite correct - the audio context does NOT transition to running automatically in Chrome on a user interaction. As of this writing, it will transition if the user interacts with the page and then a start method is called on an audio source node (e.g. a source buffer or an oscillator).

As of this writing, Chrome, which is at version 71.0.3578.98 and the version of Safari on my test MacBook Air, which is 12.0.2, handle the initial state of audio contexts pretty much the same way. In these browsers, the audio context starts out initially in the "suspended" state and automatically transitions to the "running" state on the first user interaction with the loaded page. This doesn't seem to lead to many problems for us unless the first thing the user does causes a sound to be initiated. In the Friction sim, this is often the case, and in both Chrome and Safari, the initial sound often sounds odd, generally a bit muted. This behavior can be duplicated by loading https://phet-dev.colorado.edu/html/friction/1.5.0-rc.1/phet/friction_en_phet.html and clicking on the top book in the magnifier view. I think this may also be at the root of the problematic behavior that @emily-phet reported in phetsims/friction#159 (comment) as "Issue 1".

Firefox version 64.0 behaves a little differently. As with the other browsers, it starts the audio context in the "suspended" state but during the initialization it transitions it to the "running" state without any user interaction. I'm not sure why it does this, and it may be because it somehow tracks that the sim is a trusted site of some kind, and for other sites it doesn't do this.

As for MS Edge, in version 42.17134.1.0 it starts with the audio context in the "running" state, so it would seem that at this point Microsoft isn't initially blocking sound from web sites, or are doing so using some other approach.

[jbphet]

To be clear, there does not seem to be a need to do exactly what the title of this issue suggest, which is to add code that reactivates and audio context on the first user interaction. It seems that the browsers now do this themselves. However, there are things that should potentially be done, and I'd like to keep all the information about this in one place, so I'll continue to log the activity against this issue, at least for the time being.