card label is placed at different position and stacking order in Firefox vs. other browsers at www3.animeflv.net
Categories
(Core :: Layout: Positioned, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: webcompat:platform-bug)
Attachments
(6 files)
STR:
- Load https://www3.animeflv.net/
- Scroll down to the larger thumbnails with title "Últimos animes agregados"
EXPECTED RESULTS:
The green diagonal card labels should be in front of the thumbnail images, with the top edge being just a bit higher than the image's top edge.
ACTUAL RESULTS:
The green diagonal card labels are behind the thumbnail images, and their top edge are higher than they should be (by ~1 line-height or so).
This was originally filed as https://webcompat.com/issues/60176 which we associated with bug 1573990, but there's more going on, since Chrome aligned with our behavior for bug 1573990 and yet we still disagree with Chrome on this particular scenario here.
Reporter | ||
Comment 1•9 months ago
|
||
Here's a reduced testcase, as a slightly-modified version of ksenia's codepen reduction on the github issue.
Reporter | ||
Updated•9 months ago
|
Reporter | ||
Comment 2•9 months ago
|
||
Reporter | ||
Comment 3•9 months ago
|
||
There's definitely some weird interop differences in this area. Here's a testcase where everyone seems to agree, to get things started...
Reporter | ||
Updated•9 months ago
|
Reporter | ||
Comment 4•9 months ago
•
|
||
In this one, Safari and Firefox agree (and match the behavior on testcase 3), but Chrome changes behavior -- they change the abspos CB width to fit the black-bordered-box (the CB of the inline-that-forms-an-abspos-cb), and they increase the height of the abspos containing block to fit the new block child.
Reporter | ||
Comment 5•9 months ago
|
||
This one (with multiple lines of text) is a case where we're the odd one out; we seem to only use the first line of text to define the abspos CB, whereas Chrome and Safari seem to use the union of all of the lines.
Reporter | ||
Comment 6•4 months ago
|
||
Here's a testcase from bug 1926971 which I think is a version of this same bug (likely similar to testcase 2 here RE stacking-order-differences).
As noted in bug 1926971 comment 5, if you try hovering the rects in this testcase:
- Firefox: neither rect changes color.
- WebKit (and Chrome 100-and-olde): only the lower rect changes color when hovered (i.e. WebKit needs z-index to be set on the display:inline wrapper in order for that rect to be sufficiently-in-the-foreground to be hoverable)
- Chrome (101-and-newer) both rects change color (individually) when they are hovered.
Updated•3 months ago
|
Description
•