Selection Box drops down and to the right

[KatieWoe]

Test device
Dell
Operating System
Win 10
Browser
Chrome
Problem description
For phetsims/qa#436. Not present in published version.
When stringTest is long, the box for selecting different solutes drops down instead of up, meaning several options are cut off. It also starts on the right near the button, so the reset button is covered up, instead of being in the same location as the original bar. Neither behavior is shown with the same string test in the published version.
Steps to reproduce

1. Set stringTest=long
2. Open solute menu

Visuals

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: 12345678901234567890123456789012345678901234567890
URL: https://phet-dev.colorado.edu/html/molarity/1.5.0-dev.23/phet/molarity_en_phet.html?stringTest=long&dev
Version: 1.5.0-dev.23 2019-10-04 22:27:51 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Language: en-US
Window: 1536x722
Pixel Ratio: 2.5/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: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

[twant]

I went back through all of the recent dev versions and it looks like this started happening between dev versions 1.5.1 and 1.5.2. Going to investigate each of the commits between those versions now.

[twant]

When I turn off accessibility, this error still occurs. There are a handful of commits between dev versions 1.5.1 and 1.5.2 that seem like they may have an effect on combobox behavior:

eb14a8f
499ca0c
68c2b89
68c2b89
c6ec37e

[twant]

By changing the font size of the "Solute" label on SoluteComboBox to 12 instead of 22, I can avoid this behavior.

Also, after I open and close the SoluteComboBox 3 times, it opens normally with long strings on the 4th time.

[zepumph]

@twant and I dove into this for a while. We mainly looked at ComboBox.moveListBox.

We were unable to pin down anything concrete. You can reproduce this with stringTest=long in Molarity and in Beers Law lab. Furthermore, the longer the string the further away it gets from the button. When you then apply a maxWidth to the text for the combo box items, this problem goes away (so long as the string is longer than the maxWidth, forcing a scale-down). From this we think that the issue is caused by the ComboBox somehow not respecting the scaled width of the combo box items.

The best way we found to reproduce this was to exchange drinkMixString in MolarityModel for 'fdddddddfdddddddfddddddd'. Then the combobox will be 20px up and left of the button. We then plotted points and found this descrepancy.

The most curious part of this was that sometimes we found the following two lines of code to equal each other, and sometimes they were about 20px different. Either way, the listbox was always up and left from the buttons:

        const globalFromButton = this.localToGlobalPoint( new Vector2( this.button.left, this.button.top ) );
        const globalFromListBox = this.listParent.localToGlobalPoint( new Vector2( this.listBox.left, this.listBox.bottom ) );

More random notes:

• In some but not all cases, cycling the listbox open and then closed a number of times will "bring" the listbox back to the correct location. This seemed to happen every time in BLL with stringTest=long
• wrapping setTimeout around the call to moveListBox worked sometimes, with a flicker from the origin to the correct location of the list box.

@jonathanolson could you provide a bit of feedback. It's quite possible that we are just looking in the wrong place, but when two calls of localToGlobalPoint that you would expect to be the same are not, it seems weird and hard to investigate.

[zepumph]

@twant and I worked on this again today. We didn't solve this generally, but we did find that removing the maxWidth from the list box parent solved this issue, and because of the scaling done on the list box by the combo box, we don't need the maxWidth for i18n (at least it looked good with stringTest=long). We are going to commit, close, and then look for a general solution over in phetsims/sun#542

[zepumph]

Reopening, @pixelzoom said over in phetsims/sun#542 (comment):

I'll have a look, but can't get to this until next week.

That workaround in 244e74e really doesn't look like something that should be committed to the production version of ComboBox.

Let's keep this open so that we don't think of that patch as "ready for production"

[pixelzoom]

How is reopening this issue going to keep someone from picking this "patch" up in a release branch?

[pixelzoom]

OK, now that I'm not trying to look at this on my phone, I see that 244e74e is specific to MolarityScreenView, so won't affect other sims.

[pixelzoom]

244e74e is an appropriate fix, see phetsims/sun#542 (comment). @zepumph feel free to re-close.

[pixelzoom]

@zepumph should this be closed or labeled "fixed-awaiting-deploy"? It should probably be tested by QA.

[zepumph]

Right. QA, when you get to this, you can close if all is good.

[KatieWoe]

Seems fixed on master