Firefox to implement auto-blocking of audio, we should test and make sure we handle it

[jbphet]

I just saw an article about Firefox starting to auto-block audio and video on web pages until the user interacts with the page. Hopefully, this will be handled by the code already in place to handle similar behaviors seen in Chrome and Safari, see #9.

I will also log a similar issue for the vibe repo.

[jbphet]

There is a line in the above-referenced article that makes me think that this won't affect our implementation. It says,

At this time, we’re also working on blocking autoplay for Web Audio content, but have not yet finalized our implementation. We expect to ship with autoplay Web Audio content blocking enabled by default sometime in 2019. We’ll let you know!

This makes me think that they're only blocking what I believe is the older way of playing audio from a browser, based on HTMLMediaElement, and not Web Audio.

[jbphet]

Assigning to @phet-steele at @ariel-phet's suggestion.

@phet-steele - I don't know for certain, but I suspect that Firefox has things set up similar to Chrome where it's possible to install pre-release versions and test with them. Can you please get set up to test with the upcoming version (which I believe is version 66) and test the sims that use the tambo libary and make sure they work? The published sims are John Travoltage and Resistance in a Wire, and it would be good to also check the latest Friction RC too. Also, please test the master version of the tambo demo. If you have a Mac available, please test on both Windows and Mac, otherwise, assign it to @ariel-phet when you're done so that we can figure out how to test Mac as well.

[phet-steele]

Testing suggested sims on Windows 10 with FF 66.0b7: sound works

Tambo demo on same platform: sound works

However, there was a neat interaction with the dev tools. Opening dev tools for the first time mutes all sound. Closing the dev tools, then opening the dev tools a second time brings sound back. It will even play all the sound it "queued" when sound was muted. This cycle repeats on each successive opening/closing of the dev tool. Hopefully our users on FF don't use the dev tools often 😉.

EDIT: Mac behaves identically.

[jbphet]

I took a look at the behavior with respect to the developer tools, and indeed, it seems that the audio context is being suspended when developer tools are opened. I'm seeing this on Firefox version 65.0.1, so it doesn't appear to be new. I did some online searches and see no mention of this, so perhaps I should log an issue with Firefox. I tried simply calling resume() on the audio context, and it worked fine (and played queued up sounds), so I should be able to add code to handle this situation. It seems like it would be worthwhile to do so to avoid confusion if and when we have to do some sound debugging on Firefox.

[jbphet]

@phet-steele - I've generalized the code that watches for changes to the audio context's state and "resumes" it. Please test on master and see if the weirdness that you were seeing with dev tools is now gone. It is fixed for me on Firefox version 65.0.1.

[jbphet]

For the record, I logged a bug with Mozilla about the odd behavior in Firefox where the audio context becomes suspended when the dev tools are opened. As of this writing, it looks like they have confirmed the bug. See https://bugzilla.mozilla.org/show_bug.cgi?id=1535089.

[jbphet]

I just noticed that this bug was languishing due to @phet-steele having left PhET. Assigning to @KatieWoe for followup.

[KatieWoe]

This seems to have been implemented for some time and I have not seen any major problems during my tenure here. Only thing we've seen is described here: phetsims/gravity-force-lab#252

The first sound produced by the sim seems to be a bit softer than those produced after. Seems rather minor, may be in other sims as it is hard to notice. It does seem familiar, but I couldn't find another issue of it. Probably doesn't need addressing if hard to fix.

This behavior is due to the autoplay policy that is implemented by most browsers these days. This policy prevents sound from being played by a web page until the user interacts with it. There are a number of GitHub issues related to this, and perhaps the most relevant is #9.

[p]robably doesn't need addressing if hard to fix". Given this input and the tradeoffs of addressing the problem, my recommendation is to just live with this, at least for now.