To reproduce: - Visit url testcase, and follow the steps in the testcase Afterwards, the selected option has become "1", it should have stayed "3". Mozilla1.7 and IE6 both keep the selected option "3". I very much suspect this is a regression from bug 286170 itself, since I can see the bug also in a SeaMonkey 2005-07-11 build.
This regressed between 2005-06-20 and 2005-06-22 and I've checked in my debug build that bug 295571 isn't the cause of this/
The number hovered in the moment when 5 is removed, gets set as default option. Load attachment 179320 [details], drop down the combobox menu and hover "2", and wait until "5" gets removed. "5" can't be selected when "5" is removed, so the first item gets selected.
I get the same regression range. I backed out bug 286170 locally and still see the bug though. I'll take a look...
Regression is from bug 297389. It's quite bad actually, if we get a reflow while the menu is dropped down we will select the item that is hovered by the mouse. To reproduce: 1. click on any combobox (to drop down the menu) 2. hover an item different from the currently selected value 3. text zoom (CTRL++) => combobox value changes to what was hovered
Created attachment 200412 [details] [diff] [review] Patch rev. 1
Comment on attachment 200412 [details] [diff] [review] Patch rev. 1 r+sr=bzbarsky. Please check this in on trunk ASAP and request branch approval.
Checked in to trunk at 2005-10-21 20:47 PDT. -> FIXED
This is a very safe fix that we should take on branch. All it does is make sure to not change what option is "selected" while the combobox is dropped down.
bz, what would we need to test to make sure this doesn't break anything else?
Modifications to combobox layout (text resize, DOM timeouts firing, etc) while the combobox is dropped down. The dropped-down state is the only state affected.
Checked in on branch.
Verified. Sorry for blaming the wrong bug.