Make WordPress Core

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#15848 closed defect (bug) (worksforme)

Chrome has incorrect event target in some situations

Reported by: filosofo's profile 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)

test.html (1.1 KB) - added by filosofo 14 years ago.
class-wp-editor.php.patch (444 bytes) - added by ocean90 13 years ago.
editor-buttons.diff (344 bytes) - added by trepmal 13 years ago.
"fixes" issue for me

Download all attachments as: .zip

Change History (22)

@filosofo
14 years ago

#1 @filosofo
14 years ago

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.

#2 @demetris
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

#3 @chrisbliss18
14 years ago

Confirmed on Ubuntu 10.10 with the latest daily build: 11.0.679.0 (75530)

#4 @filosofo
14 years ago

I've noticed this issue causes problems in Basecamp too.

#5 @duck_
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).

#6 @ocean90
13 years ago

Chrome 13 on Mac too.

#7 @ocean90
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

#8 @trepmal
13 years ago

Also Chrome 15.0.874.83 beta on Mac

#9 @nacin
13 years ago

  • Milestone changed from Future Release to 3.3
  • Priority changed from lowest to high
  • Severity changed from trivial to blocker

#10 @nacin
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.

#11 @nacin
13 years ago

  • Keywords needs-testing needs-isolating added

This could also be hoverintent.

#12 @ocean90
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.

#13 @ocean90
13 years ago

Also disabling JS doesn't help...

#14 @ocean90
13 years ago

It's something in editor-buttons.css

@trepmal
13 years ago

"fixes" issue for me

#15 follow-up: @trepmal
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...)

#16 @ocean90
13 years ago

Nice, yes it's cursor:pointer.

If the CSS is loaded in the head it works too.

Last edited 13 years ago by ocean90 (previous) (diff)

#17 @azaozz
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.

#18 in reply to: ↑ 15 @azaozz
13 years ago

Replying to trepmal:

#18868 fixes the "flashing" of the first admin bar menu while the page is loading as far as I can see however specifying the default cursor on links isn't needed too.

#19 @azaozz
13 years ago

In [18935]:

Remove unneeded cursor style, props trepmal, see #15848

Note: See TracTickets for help on using tickets.