<select> item selection broken when used in a tr with hover styling

NEW
Unassigned

Status

()

Core
Layout: Form Controls
P3
normal
7 years ago
4 months ago

People

(Reporter: Reece H. Dunn, Unassigned)

Tracking

(Blocks: 1 bug, {regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(e10s-, blocking2.0 -)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Created attachment 514205 [details]
Sample HTML that reproduces the issue.

Comment 2

7 years ago
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?
Component: General → Layout: Form Controls
Keywords: testcase
Product: Firefox → Core
QA Contact: general → layout.form-controls
Version: unspecified → Trunk
(Reporter)

Comment 3

7 years ago
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?

Comment 4

7 years ago
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
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression, regressionwindow-wanted

Comment 5

7 years ago
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?
blocking2.0: ? → -
(Reporter)

Comment 7

7 years ago
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).
(Reporter)

Comment 8

7 years ago
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

Comment 9

7 years ago
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
blocking2.0: - → ---

Comment 10

7 years ago
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
Blocks: 621601
blocking2.0: --- → ?
Keywords: regressionwindow-wanted
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.
OS: Windows 7 → All
Hardware: x86 → All
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

Comment 15

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

Updated

7 years ago
No longer blocks: 621601
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.
blocking2.0: ? → -
Keywords: regressionwindow-wanted
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.
Flags: needinfo?(msclrhd)
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.
Blocks: 1154677
Flags: needinfo?(msclrhd)
Keywords: regressionwindow-wanted
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
tracking-e10s: --- → ?
(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
tracking-e10s: ? → -

Updated

4 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.