1487937 - Pointer events don't make it to a float in relatively positioned block-in-inline split (with content before & after the float)

Status: NEW

(Core :: Layout: Floats, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:
 1. Load attached testcase.
 2. Hover the link. Try to click it.

EXPECTED RESULTS:
Background should change to indicate hover state.
Cursor should change on hover & click (and text color should change on click), as it normally does for a link.

ACTUAL RESULTS:
The cursor & the link's rendering doesn't change at all when I hover/click the link.

Edge, WebKit, and Blink all give EXPECTED RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (broken in Blink/WebKit, too; working correctly in Edge)

Comment 2

[Karl Dubost💡 :karlcow]

hmm I tried to test this on WebKit, Blink, and Gecko latest versions on macOS

• Testcase 2 is not working anywhere.
• testcase 1 is working only in Safari Release 136 (Safari 15.4, WebKit 17613.1.9.2)

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Karl Dubost💡 :karlcow from comment #2)

• Testcase 2 is not working anywhere.

This fact hasn't changed since the bug was filed -- as noted in the attachment-title, it only ever worked in EdgeHTML (which is no longer relevant).

• testcase 1 is working only in Safari Release 136 (Safari 15.4, WebKit 17613.1.9.2)

Interesting. It used to work in Chrome; I just bisected old versions and it seems that it still worked in Chrome 75, and stopped working in Chrome 76. Not sure if that was due to a bugfix or a regression.

I don't really know what's going on or why it would make sense to eat pointer events here, but maybe we don't need to worry about this, given that we're relatively interoperable at this point? (and maybe there's a subtle reason that the interoperable but broken-feeling behavior is correct?)

Note that testcase 2 (where all modern browsers agree) is the same as testcase 1, except that testcase 1's border on the span has been removed in testcase 2. I don't see any reason why that border's presence/absence should make a difference for pointer events... So it could be that Safari just happens to get lucky with the border present (in testcase 1) but really the interoperable behavior on testcase 2 is correct?

Anyway, I think we can easily downgrade this to lowest-priority. I'm tempted to close it except the behavior still feels broken, even if it's interoperable, and I'd kinda like to understand why it's correct before closing it. :)

Comment 4

[Dennis Schubert [:denschub]]

Since Chrome now aligns with Firefox, this probably isn't a Firefox WebCompat issue anymore. Unsetting the priority flag for now.

Comment 5

[Ian Kilpatrick [:iank]]

We (Blink) have recently fixed this bug - should be changing in M101.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks! I can confirm that testcase 1 and 2 are currently working (i.e. hovering the text makes the background green), in Chrome dev channel, Version 101.0.4947.0 (Official Build) dev (64-bit)

Testcase 2 is still broken in WebKit (Safari 15.4), but testcase 1 continues to work there.

Both testcases are broken in Firefox Nightly 100.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Dennis Schubert [:denschub] from comment #4)

Since Chrome now aligns with Firefox, this probably isn't a Firefox WebCompat issue anymore. Unsetting the priority flag for now.

Looks like we should perhaps re-set it, given comment 5. (Probably low webcompat impact at the moment given that Chrome's been shipping a behavior like Firefox's for some number of months at least, but given they needed to fix that, we probably will need to do so as well.)

Comment 8

[Daniel Holbert [:dholbert]]

(IanK, do you happen to have the Chrome bug handy where you fixed this behavior?)

Comment 9

[Ian Kilpatrick [:iank]]

This is: https://bugs.chromium.org/p/chromium/issues/detail?id=716930 (slightly bad bug name) we are changing how we represent block-in-inlines, and just picked up as part of that. Don't know if I have a more specific bug sorry.

(we now will start applying filters etc, for blocks inside inlines with this change matching FF).

Comment 10

[Ksenia Berezina [:ksenia]]

Given that https://github.com/webcompat/web-bugs/issues/17569 is now showing a log in pop up preventing access to the site, it's unclear whether the issue is still present, or whether the site is still being used. Based on that, unsetting webcompat priority for now (the testcase 2 is still reproducible).