User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre If a <select> element is in a <tr> element with hover styling (tested with background-color), item selection goes wonky. Reproducible: Always Steps to Reproduce: 1. Hover over line -- line is updated with the tr:hover styling 2. Click on the select item -- the select options appear in the drop-down; tr:hover styling still applied 3. Move the mouse down to the first item -- tr:hover styling still applied 4. Move the mouse to the left, out of the drop-down area -- item selected; tr:hover styling not applied 5. Move down next to the second item in the drop-down, but *not* across (i.e. don't move onto the item, move next to it) 6. Move to the right, onto the second item -- the tr:hover styling is applied; the item is not selected 7. Move down to the third item -- the tr:hover styling is applied; both the first and third items are selected 8. Move up to the second item -- the tr:hover styling is applied; both the first and second items are selected 9. Move up to the first item -- the tr:hover styling is applied; only the first item is selected 10. Move down to the second item -- the tr:hover styling is applied; only the second item is selected Actual Results: 6. The item should be selected (in addition to the tr:hover styling being applied). 7. & 8. Only the first item should be selected It looks like the style change event for the tr:hover is stealing/clearing the capture of the <select> combobox and the combobox is not handling the "release capture when the mouse is not over the items drop-down panel". You can move the mouse over and off the drop-down area as many times as you want; only the tr:hover state will be applied.

Works for me using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre ID:20110222030357 Although not so sure about step #5 and whether I've interpreted it correctly? Could you try with safe mode/new profile please: http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_make-a-new-profile Also, does this work ok in 3.6.13?

This works as expected on 3.6.13 (Linux) and I have reproduced using Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110221 Firefox/4.0b12pre in normal and safe mode. I have seen this work as expected on 4.0b12pre occasionally (situation seems variable on (i) delay between steps 4-6 (ii) distance moved by the mouse (iii) random). Steps 4-6 are moving the mouse left (4), down (5) and right (6) such that it moves away from the first item in step (4) and onto the second item in step (6). Does this make more sense?

Weird, worked earlier, but now can replicate just fine using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre ID:20110222030357

Since it seems to occur more readily for you, would you mind trying to find out the regression range? http://harthur.github.com/mozregression/ Thanks!

Can you renominate once you get a regression range?

This is a really difficult issue to track down a regression range (at least on the Linux box I have). I have now seen this issue on 3.6.13 Linux (safe-mode after 2 browser restarts and ~20 tries each). It appears to get more frequent with later releases. The best I can do at the moment is: 2010-06-01-03-mozilla-central - 3.7a5pre reproduce 2/5 runs [1] 2010-07-01-03-mozilla-central - 4.0b2pre reproduce 5/5 runs [2] [1] after ~20 attempts each run [2] on the first attempt for 4/5 runs and the second attempt on the second run I can reproduce this back in 1 month increments to 2009-12-31-03-mozilla-central. I haven't tried earlier builds (except for 3.6.13).

NOTE: The above tests in comment 7 are with a clean profile running: ./firefox -safe-mode -no-remote -P test https://bug635928.bugzilla.mozilla.org/attachment.cgi?id=514205

Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/e807269acaa3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre ID:20110119030331 Fails: http://hg.mozilla.org/mozilla-central/rev/710c1a6faf99 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre ID:20110119003149 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e807269acaa3&tochange=710c1a6faf99 It works if set layers.acceleration.disabled to true

In local build: buildfrom e807269acaa3 : works buildfrom 0eddf5b448bb : works buildfrom a18080aa75d6 : works buildfrom 4fc581f1ff00 : fails(if set layers.prefer-d3d9 to true) buildfrom 1d293c9ffa95 : fails buildfrom 710c1a6faf99 : fails Triggered by: 1d293c9ffa95 Robert O'Callahan — Bug 621601. Part 3: Implement EndEmptyTransaction for D3D10. r=bas,a=joe 4fc581f1ff00 Robert O'Callahan — Bug 621601. Part 2: Implement EndEmptyTransaction for D3D9. r=bas,a=joe Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110228 Firefox/4.0b13pre ID:20110228030400 Graphics Adapter Description: ATI Radeon HD 4300/4500 Series Vendor ID: 1002 Device ID: 954f Adapter RAM: 512 Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version: 8.821.0.0 Driver Date: 1-26-2011 Direct2D Enabled: true DirectWrite Enabled: true (6.1.7601.17514, font cache n/a) WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) GPU Accelerated Windows: 1/1 Direct3D 10

The patch in bug 636817 might fix this.

(In reply to comment #11) > The patch in bug 636817 might fix this. Unfortunately, it doesn't.

Oh, and I'm using GNU/Linux and I can reproduce this issue on trunk but not on 3.6 even with layers.acceleration.disabled sets to true (I didn't try to set layers.prefer-d3d9 to true...).

It's also reproducible on Mac, the regression range I find is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd26cf0fd809&tochange=b3e305eb173c

I misread str. The regression range in comment #9 and comment #10 may be another bug.

Don't think that this pattern is common enough to block on it. If it can be tied to a top site not working, please renominate.

The regression range in comment 14 doesn't match what I get on Linux. The frequency of this problem (and the ease in reproducing) has certainly increased with time, but I've reproduced the problem at least as far back as 2010-01-15 (and that's where I stopped trying, so further back yet).

I get what looks like consistent behavior in current builds these days. Can you reproduce? There actually does appear to be an issue on nightly builds w/ e10s enabled (the red hover-over goes away when you hover over the drop-down area in step #3), but that should probably be tracked in a new bug as an e10s-specific issue.

e10s seems to make our broken behaviour here slightly more broken. Maybe that's worth filing a new bug about, but for now, just putting in the dependency.

Hi, I was able to reproduce this on Windows 10, Windows 7, Ubuntu 14.04 and Mac OS X 10.6.8 on the latest Aurora (46.0a2) with e10s enabled. With e10s disabled the red hover-over does not go away when you hover over the drop-down area in step #3. Build ID 20160203004041 User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:46.0) Gecko/20100101 Firefox/46.0 Thanks, Cipri

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #19) > e10s seems to make our broken behaviour here slightly more broken. Maybe > that's worth filing a new bug about, but for now, just putting in the > dependency. Filing a new bug for the "slightly more broken" is the right thing to do here wrt e10s