fix: initialize audio context only with user interaction

[watilde]

Resolves

• Resolves (partially) The AudioContext was not allowed to start. #4514

Proposed Changes

Add a one-dispatch event listener to trigger the shared audio context.

Reason for Changes

To help developers to debug by removing a warning.

Test Coverage

Added new unit tests for shared-audio-context.js.

Browser Coverage

Check the OS/browser combinations tested (At least 2)

Mac

• Chrome
• Firefox
• Safari

Windows

• Chrome
• Firefox
• Edge

Chromebook

• Chrome

iPad

• Safari

Android Tablet

• Chrome

[benjiwheeler]

This seems like a simple fix that should not be hard to test

[apple502j]

Hmm, I have a question... isn't that startaudiocontext's purpose?

[watilde]

@apple502j That's right. We can leverage https://github.com/tambien/StartAudioContext instead as well. @benjiwheeler What do you think? Please nvm. I misunderstood.

Let me also add a test for this.

[apple502j]

Hmm, I don't think we need startaudiocontext because the thing is already implemented. Also, https://github.com/LLK/scratch-audio/blob/develop/src/StartAudioContext.js may also need this fix

[watilde]

@apple502j That's good to know, thank you. As the original issue still exists, we still need to have new audio context initialization. Turned out the audio context initialization issue exists in three places.

Here is a screenshot on Chrome from the latest develop branch(hash).

Where the issue happens

1. src/lib/audio/shared-audio-context.js#6
This PR fixes this issue. Line: https://github.com/LLK/scratch-gui/blob/cc22bfc636f86b56b43e8422084a3b64a63e875a/src/lib/audio/shared-audio-context.js

2. node_modules/audio-context/index.js#36
We need to have another patch to fix it. This call is from node_modules/scratch-audio/src/AudioEngine.js that calls StartAudioContext you mentioned.

3. node_modules/startaudiocontext/StartAudioContext.js#114
This will no longer be an issue if we fix the above two. This is just the place where scratch-gui calls AudioContext.

[watilde]

@benjiwheeler Thank you for your comment. I just added tests.

[paulkaplan]

This PR causes a bug where the sound tab will crash due to undefined audio context in the situation where you have a device with ontouchstart defined but not used, for example on certain devices with a touchscreen and a trackpad mouse. Also

Hmm, I have a question... isn't that startaudiocontext's purpose?

Yeah @apple502j it definitely is, so I'm pretty confused about why it wasn't working. Ideally we can remove any synchronous uses of AudioContext and move everything to a promise, although that might be hard because we may rely on synchronous access to the audio context in many places.

A simple fix for right now will be to just bind to both those events and unbind both to cover the bases, although that still leaves open the 2 questions: (1) why startaudiocontext wasnt doing its job, (2) is there a way to not rely on audiocontext being available right away.