Mirror-inputs wrapper quickly is out of sync after keyboard nav & Reset All

[phet-steele]

It is more obvious when interrupting towards the end of the discharge (when there are about to be no electrons left):

The sims will end up with differing amounts of electrons, leading to different discharge occurrences (about halfway in the video the bottom one discharges while the top does not):

Seen on macOS 10.12.3 Chrome. For phetsims/tasks/issues/780.

[EthanWJohnson]

Possibly a macOS specific issue; I'm unable to get the same to occur in win10.

[samreid]

I'm not seeing any rand calls or Date.now that might lead to a divergence of playbacks.

[samreid]

Likewise there are no lodash random calls.

[samreid]

I tested for a minute and could not create any discrepancies in the mirror wrapper.

[phet-steele]

@samreid @jessegreenberg I know how to make this happen consistently (although, I don't know why). It is very much reliant on keyboard nav. Here is a controlled setup to demonstrate:

1. Tab to the leg in the top sim
2. Move the leg with the arrow keys in slow increments until you grab one electron. The bottom will not grab an electron (this is expected).
3. Every step after this is with a mouse. Click Reset All.
4. Grab the leg at the top and move it very slowly until the first instance where you pick up electron(s). The two sims should then grab differing numbers of electrons.

I do not believe you need to do this procedure slowly to see the issue, but doing it slowly is more demonstrable. Subsequent Reset Alls will not re-sync the sims, you must refresh the browser.

[phet-steele]

@EthanWJohnson was successful in reproducing on Win 10.

[jessegreenberg]

This issue seems related to keyboard navigation or the main model, assigning myself to take a look.

[jessegreenberg]

@phet-steele did the example in #194 (comment) also use keyboard navigation first?

[phet-steele]

@phet-steele did the example in #194 (comment) also use keyboard navigation first?

More than likely. At the time of recording, it was certainly not apparent that keyboard nav was a necessary part of the procedure. #194 (comment) is the most informed report.

[jessegreenberg]

Ok, great, thanks!

[jessegreenberg]

There are two parts of this issue. First, the number of electrons in the body can become out of sync as shown in #194 (comment). Second, positions of electrons in the body can become out of sync, as shown in #194 (comment).

The above commit fixes the first part of the issue. The second part of the issue is because JohnTravoltageModel.addElectron calls phet.joist.random.nextDouble() to place the electron in a random spot in the foot. In the input frame, we go through the random number sequence as electrons are added with the keyboard. So the position in the random number sequence is getting behind in the mirror input frame when we use the keyboard. From then on, all electron positions in the body are out of sync.

The best fix for this is probably to get phet-io to capture all keyboard events.

[jessegreenberg]

This issue illustrates an problem in the overlap between phet-io and accessibility, not sure if it should remain at high priority.

@ariel-phet should this be a high priority issue?

[ariel-phet]

@jessegreenberg I do not think this issue should remain at high priority. iO and a11y will need to "play nice" in the long run, so it is worth some investigation, but since iO strategy is still in flux, I don't think we need to have a perfect fix/overlap just yet. Good to understand the "why" but not necessarily make things perfect yet.