iOS Safari often doesn't trigger start or end events on SpeechSynthesisUtterance

[jessegreenberg]

While working on related issue phetsims/number-play#134 (comment) and #65 I am seeing that the start and end event listeners frequenly fail to fire in iOS Safari. Causing an assertion in UtteranceQueue because the this.announcingUtteranceWrapper isn't cleared on the end event. And reading blocks do not highlight because the start event doesn't fire.

I tried re-introducing the safari workaround removed in #52, but it doesn't seem to fix it always. Though maybe it is better? It is hard to say, it seems to happen randomly.

[jessegreenberg]

I am not too interested in finding a way to "trick" Safari into always firing these events. It seems too unpredictable. Instead I am wondering if we can find a way to handle this gracefully and fallback to some behavior when we don't get these events.

[jessegreenberg]

Stream of consciousness notes to help think it through...

Sometimes we don't get a start event or an end event and synth.speaking is false. It is as though we never requested speech in SpeechSynthesisAnnouncer. But listeners are added in UtteranceQueue assuming they will be removed by the end event that we never get.

We need to gracefully handle these failure cases somehow, detecting when we request speech but speech never starts. This way the SpeechSynthesisAnnouncer can notify the UtteranceQueue that listeners should be removed.

Proposal: Keep track of when speech is requested in SpeechSynthesisAnnouncer. If synth.speaking is not true in a reasonable amount of time then we can assume there has been a failure and we will get no events nor start speaking. We cancel the synth and remove listeners. Something to think about is adding this failed utterance to the back of the queue again to try until we have a success.

EDIT: Although, if we keep track of the time before the start event instead of the time before synth.speaking becomes true then this workaround may also work for the ChromeOS issue in phetsims/number-play#138 (comment)

[jessegreenberg]

The proposal is working really well so I'm going to commit it. The fundamental changes are

1. There is now a pendingUtterance on SpeechSynthesisAnnouncer that is set immediatelety in requestSpeech. It's existence well prevent the Announcer from setting readyToSpeak = true so that the UtteranceQueue cannot announce anything if we are still waiting for something to speak. It could take longer than VOICING_UTTERANCE_INTERVAL between the call to getSynth().speak() and the time getSynth().speaking becomes true.
2. If the amount of time between setting the pendingUtterance and the start event is greater than PENDING_UTTERANCE_DELAY we can assume there has been a failure of the engine and we cancel speech and remove listeners before the next attempt to speak.

[jessegreenberg]

Next, I want to fix #65 and then Ill be able to verify if this is fixed in number-play where it was originally found. Finally, Ill check and see if this is working in ChromeOS.

[jessegreenberg]

#65 is resolved and number-play is working well in iOS Safari. The failure case is now being detected but not handled in ChromeOS. Lets continue that part of the issue in #64.

@zepumph could you please review the two commits here and the summary of these changes in #66 (comment)?