Chrome has incorrect event target in some situations

[filosofo]

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.

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.

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

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

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

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

Chrome 13 on Mac too.

Also Chrome 15.0.874.83 beta on Mac

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.

This could also be hoverintent.

This could also be hoverintent.

I'm not sure. At the moment it happens for me on dashboard and edit post/page screen.

Also disabling JS doesn't help...

It's something in editor-buttons.css

"fixes" issue for me

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

Nice, yes it's cursor:pointer.

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

Don't see this happening any more, seems fixed in Chrome.

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.

In [18935]:

Remove unneeded cursor style, props trepmal, see #15848