#15848 closed defect (bug) (worksforme)
Chrome has incorrect event target in some situations
Reported by: | filosofo | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Severity: | blocker | Version: | 3.1 |
Component: | General | Keywords: | needs-patch needs-testing needs-isolating |
Focuses: | Cc: |
Description
The result is that clicking a select element triggers a mouseover event on an element not in its ancestry. In the case of the WordPress admin, this means triggering the hover state on the admin bar (which reveals the dropdown sub-menu).
I can reproduce this in Chrome 8.0.552.224 on Linux but not Chrome 8.0.552.224 on Windows.
Attached is a page simplified to the bug's barest essentials. Change #some-element's position
, top
, or left
CSS properties, and the bug does not occur. (The borders and positioning on the select element are just to make it clear that there's no overlap of the elements.)
I will report this upstream to Chrome. There are several options to prevent it from happening, but they're somewhat hacky. I'm going to see if I can come up with less-hacky solution before creating a patch.
Attachments (3)
Change History (22)
#2
@
14 years ago
The problem still exists in Chromium 9 for Linux. Confirmed in:
- 9.0.597.94 (73967) Ubuntu 11.04
- 9.0.597.98 (74359) Built on Debian unstable, running on Debian wheezy/sid
#5
@
13 years ago
Closed #17681 as dupe which reports issues with Chrome 11 and 12 on Windows 7 as well as on Linux (both admin bar and the folded admin menu).
#7
@
13 years ago
- Summary changed from Chrome on Linux Has Incorrect Event Target in Some Situations to Chrome has incorrect event target in some situations
#9
@
13 years ago
- Milestone changed from Future Release to 3.3
- Priority changed from lowest to high
- Severity changed from trivial to blocker
#10
@
13 years ago
- Milestone changed from 3.3 to 3.2.2
If this hits Chrome's stable channel, this is going to bite a lot of people.
This is now getting triggered on page load. Either that's because we're altering a select on those pages, or it's something new.
We need to isolate this in a self-contained HTML file, as filosofo had done. While his Chromium ticket has been ignored, now that this is a big problem, if we can properly isolate this quickly, a few of us may be able to get it escalated.
Setting to 3.2.2. If there's something we can adjust on our end, it should ship quickly if we're unable to gain traction upstream.
#12
@
13 years ago
This could also be hoverintent.
I'm not sure. At the moment it happens for me on dashboard and edit post/page screen.
#15
follow-up:
↓ 18
@
13 years ago
I can't explain it, but removing cursor:pointer
from the .wp-media-buttons a {} style seems to "fix" the problem. Is cursor:pointer
needed on the anchor?
('fix' is in quotes only because I can't see how it would cause a problem in the first place...)
#17
@
13 years ago
- Milestone 3.2.2 deleted
- Resolution set to worksforme
- Status changed from new to closed
Don't see this happening any more, seems fixed in Chrome.
Like a chump I didn't bother building a development version of Chromium to see if it's still an issue, but I did report it.