Clean up container controls' visual cue in games

[phet-steele]

In FMN, FI, and BAF games, levels begin with the container controls active. If we are wanting to keep this behaviour, we could probably clean it up a bit. I've spotted two "issues" to look at:

1. Clicking anywhere away from the container dismisses the controls. This notably includes the back arrow button. Clicking this button, then returning to the same level, will now have the container controls hidden. It totally makes sense why this happens (level states are saved through level transitions) but whatever visual cue we are going for when entering a level is lost in this case.

2. On every refresh of a level, the container controls become active yet again, except when you double click the refresh button! Double clicking starts a level without the controls being visible.

@ariel-phet I don't find these to be particularly important or satisfyingly solvable, but more of a visual nuisance.

Seen on Win 10 Chrome. For phetsims/qa/issues/250.

Troubleshooting Information

URL: https://phet-dev.colorado.edu/html/build-a-fraction/1.0.0-dev.17/phet/build-a-fraction_en_phet.html
Version: 1.0.0-dev.17 2019-01-04 01:10:24 UTC
Features missing: touch
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Language: en-US
Window: 1920x938
Pixel Ratio: 1/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4095
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 16384x16384
OES_texture_float: true

[amanda-phet]

I could go either way with the first issue, but if we keep the controls visible after a refresh it seems like they should also be visible after clicking back and then back into the level.

Double-clicking the refresh button is unusual and it seems like it is registering the first click as refresh and the second click as "clicking away" so I don't think we need to pursue this use case.

[ariel-phet]

@jonathanolson I don't think we need to worry about double clicking the refresh button (as @amanda-phet that is very nonstandard usage).

It would be nice to fix @phet-steele (1) observation...if clicking the back arrow and then re-entering a level it would be nice if the visual cues reappeared.

This fix is not a showstopper, if it is complicated or tricky, feel free to defer for after 1.0 publication.

[jonathanolson]

Implemented (1), can you verify?

[phet-steele]

@jonathanolson I'm not getting the cues to return in at least this scenario. Do we want to handle this?

1. Have >1 containers in the play area.
2. Return one to the tool box and/or use one to make (and accept) a correct answer.
3. Return to level select.
4. Return to the level in step 1.

@jonathanolson wouldn't it be easy to say "select any existing group if there is no previously selected group"?

[ariel-phet]

@jonathanolson if this is anything but a super quick fix, it is low priority (and not a show stopper at all) for 1.0

[jonathanolson]

Should be fixed (was easy), @phet-steele can you verify?

[KatieWoe]

@jonathanolson this is implemented. I have noticed that if you un-highlight the container, leave the level, and then come back the containers will be highlighted. Is this desired? If so, then this can be closed for 1.0.0-rc.1

[jonathanolson]

I have noticed that if you un-highlight the container, leave the level, and then come back the containers will be highlighted. Is this desired?

@ariel-phet or @amanda-phet, is there a problem with this?

[amanda-phet]

I have noticed that if you un-highlight the container, leave the level, and then come back the containers will be highlighted. Is this desired?

@ariel-phet or @amanda-phet, is there a problem with this?

Nope, that sounds consistent to me.

[jonathanolson]

Closing, thanks!

[samreid]

One minor change after ObservableArray got new assertions, @jonathanolson can you please double check?

[jonathanolson]

Looks good!