WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#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)

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

Download all attachments as: .zip

Change History (22)

filosofo3 years ago

comment:1 filosofo3 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.

comment:2 demetris3 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

comment:3 chrisbliss183 years ago

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

comment:4 filosofo3 years ago

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

comment:5 duck_3 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).

comment:6 ocean903 years ago

Chrome 13 on Mac too.

comment:7 ocean903 years ago

  • Summary changed from Chrome on Linux Has Incorrect Event Target in Some Situations to Chrome has incorrect event target in some situations

comment:8 trepmal3 years ago

Also Chrome 15.0.874.83 beta on Mac

comment:9 nacin3 years ago

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

comment:10 nacin3 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.

comment:11 nacin3 years ago

  • Keywords needs-testing needs-isolating added

This could also be hoverintent.

comment:12 ocean903 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.

comment:13 ocean903 years ago

Also disabling JS doesn't help...

comment:14 ocean903 years ago

It's something in editor-buttons.css

trepmal3 years ago

"fixes" issue for me

comment:15 follow-up: trepmal3 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...)

comment:16 ocean903 years ago

Nice, yes it's cursor:pointer.

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

Version 0, edited 3 years ago by ocean90 (next)

comment:17 azaozz3 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.

comment:18 in reply to: ↑ 15 azaozz3 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.

comment:19 azaozz3 years ago

In [18935]:

Remove unneeded cursor style, props trepmal, see #15848

Note: See TracTickets for help on using tickets.