Improper keyboard nav behavior and sounds

[KatieWoe]

Test device
Dell
Operating System
Win 10
Browser
Firefox
Problem description
For phetsims/qa#601. There seem to be a number in keyboard nav sounds that play at improper times or sound off. When tabbing around either screen, sometimes a donk sound will play, mostly when over the hands, but not always. These sounds also don't sound very clean.

Even more odd, if you leave the tab to report a problem, when you come back it plays a sound, and keyboard prompts (such as arrows over hands) appear and a dropping sound plays when you click something else.

Visuals
Report a Problem:
https://user-images.githubusercontent.com/41024075/106821036-ab6abc00-6639-11eb-830e-6e55090a2803.MOV

Sounds While Tabbing
https://user-images.githubusercontent.com/41024075/106821073-bb829b80-6639-11eb-893e-a4a70e637396.MOV

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: ‪Ratio and Proportion‬:‪Ratio and Proportion‬
URL: https://phet-dev.colorado.edu/html/ratio-and-proportion/1.0.0-rc.1/phet/ratio-and-proportion_all_phet.html?stringTest=double
Version: 1.0.0-rc.1 2021-01-26 23:41:16 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Language: en-US
Window: 1280x687
Pixel Ratio: 1.5/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0
Vendor: Mozilla (Mozilla)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

[KatieWoe]

The aspect where keyboard nav sounds may play seems like it may also happen with the PhET Website link. Although, so far it seems to only make the sound as you leave, rather than when you come back. Will update this comment if that changes.

[KatieWoe]

Actually, after doing a bit more exploration, this may be in Firefox only.

[zepumph]

RE: the tabbing around problem: When tabbing around, this is because of how I defined the "isBeingInteractedWithProperty" in the Both hands interaction. In the RC version, when you have the hands in a position where the staccato sound would play, you can highlight the both-hands interaction and press "h" and the staccato sound will begin, even though "h" doesn't do anything. Above I changed it so that you have to interact with the both hands interaction in a way that the both-hands interaction expects in order to get the staccato sound to be enabled.

RE the report a problem sounds:

This is because we chose to make highlight sounds occur on focus and blur for the ratio hands. I think this has something to do with the logic with display.focusHighlightsVisibleProperty. I would like to ask @jessegreenberg if this is behaving as expected, perhaps tomorrow during our dev meeting.

[jessegreenberg]

Hmm, the "report a problem" case is odd and I am not sure what is happening there. I tried to recreate it but I wasn't able to. It looked like in the video this was all happening from mouse interaction, is that right @KatieWoe? Do you remember any other interactions made to the sim before then to get it to happen?

[KatieWoe]

It was mouse. It would happen right away without any special interactions from what I could see. But it did seem unique to firefox.

[jessegreenberg]

Sorry, I see now that it is specific to Firefox and I just confirmed that it is happening there (but not in Chrome). For some reason, Firefox is moving focus to the first input in the page this case. It seems like usually Firefox tries to put focus back at the same element that had focus when tabs changed. In this case that is probably the first menu item of the PhET Menu because that element always gets focus now when the PhET menu is opened. But then it doesn't exist anymore, so maybe Firefox is defaulting to the first element in the page in that case?

Anyway, I could see this being a little confusing. Maybe we could prevent this by bluring when the tab becomes visible again with visibilitychange event?

[zepumph]

It seems like usually Firefox tries to put focus back at the same element that had focus when tabs changed.

I think it is more that the default handleFocusCallback for MenuItem (which applies to report a problem link). This will auto focus the first element in the sim. On Firefox, this actually adds the focusHighlight, but on all platforms it is calling "firstElement.focus()" and since we are using a mouse, the display's focusHighlightVisibleProperty is false.

Note a bug here that applies to all browsers is that when you are on the report a problem page, and "go back" to the sim, you will hear the "pick up" sound because the first hand had "focus" called on it.

As for the focus highlight bug on firefox, it seems like this issue is directly related to how we want focus highlight to show up when you first tab into the sim on startup (in a general case).

[zepumph]

After discussing with @jessegreenberg, we fixed the focus callback logic in PhetMenu so that focus went back to the PhetButton.

The actual bug on Firefox will have to stay if we want to support focus highlights on the first tab into a sim in general. We think it is most clear that the focus is on the PhetButton if at all. I will cherry-pick these to the branch.

[zepumph]

@KatieWoe, can you please review these two issues on master now?

[KatieWoe]

Looks fixed on master. Checked Win 10 Chrome and Firefox

[zepumph]

Cherry-picked

[KatieWoe]

Looks good in rc.2