overflow-anchor difference in behavior compared to Chrome
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
People
(Reporter: dev.lukaszpolowczyk, Assigned: emilio)
References
(Blocks 1 open bug, )
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
Open this:
https://www.wykop.pl/wpis/39850511/xd-humorobrazkowy-film-avengers-heheszki/
Click "Kliknij aby rozwinąć obrazek" on bottom image when image top is over page viewport.
Actual results:
The image unfolds up.
Expected results:
The image should reveal itself down.
This page behaves in Google Chrome.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Hi reporter,
Thank you for taking the time to add this report.
I was able to reproduce the behavior you described across all the latest Firefox builds and OS-es (windows 10, Ubuntu 18.04 and Mac OS 10.14).
I am going to add this to Core: Document Navigation component for an advised input. If this is not the proper component, please feel free to change it to a more appropriate one.
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Where are you specifying overflow-anchor: none
?
If I turn on layout.css.scroll-anchoring.highlight
, then I see that the votersContainer
element is getting selected as an anchor on Firefox. If I specify overflow-anchor: none
on that element I properly get the desired effect.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Where are you specifying
overflow-anchor: none
?If I turn on
layout.css.scroll-anchoring.highlight
, then I see that thevotersContainer
element is getting selected as an anchor on Firefox. If I specifyoverflow-anchor: none
on that element I properly get the desired effect.
Do not understand the question.
This is not my site, I'm just a user.
It works fine in Chrome, so I think you should do as it does in Chrome. I gave a gif how it looks in Chrome.
There should be no requirement to use overflow-anchor: none;
anywhere in this case.
Assignee | ||
Comment 5•5 years ago
|
||
I see, thanks, I was confused by the bug title then. I attached a reduced test-case for the issue.
I think per https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection, we're right. In particular:
The anchor node is either a non-anonymous block box or a text node.
Where block box is https://drafts.csswg.org/css-display-3/#block-box. An inline-block
element is clearly not a "block box", so the next anchor node is the text, which is what Firefox chooses, and why we preserve the offset relative to the text and not the red box.
I'll file an issue on the specification to get a clarification on the Chromium behavior.
Assignee | ||
Comment 6•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
So the Chrome folks replied saying that this is an issue in the specification they wrote, sigh.
I'll fix Gecko (to follow what model though? There's no spec).
Assignee | ||
Comment 8•5 years ago
|
||
I have even more questions in the spec issue. I think the Chrome behavior of skipping inlines but not inline-blocks makes no sense.
Assignee | ||
Comment 9•5 years ago
|
||
Per the discussion in https://github.com/w3c/csswg-drafts/issues/4247.
Assignee | ||
Comment 10•5 years ago
|
||
I proposed something in the issue, implemented above.
Comment 11•5 years ago
|
||
Comment 14•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•