nsLayoutUtils::GetNearestScrollableFrame might return an unexpected frame
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
People
(Reporter: hiro, Unassigned)
References
Details
Attachments
(2 files)
Maybe this is not an issue at all, but bug 1560237 has one of such test cases in the case where both <body> and <html> have CSS properties which are propagated from <body> to <html>.
|
Reporter | |
Comment 1•5 years ago
|
||
A wrong bug number. :/ Sorry for confusion.
|
|
Reporter | |
Comment 2•5 years ago
|
||
The problem may not be in nsLayoutUtils::GetNearestScrollableFrame. Attaching example has styles that html { overscroll-behavior: none; } and body { overflow-x: hidden; }, with these styles we have two scrollable frame, one is for <html> and the other is for <body>. So in terms of GetNearestScrollableFrame the function works as expected. It returns the scrollable frame for <body> if it gets called for a child element in the body element.
So the problem in question is we do something when we try to get the nearest scrollable frame for position:sticky elements?
|
||
Comment 3•5 years ago
|
||
Isn't that what I said in bug 1560237 comment 1?
If you mix them, you really have two scrolling boxes (the viewport, and the <body>), and thus sticky, which only works on the closest ancestor, doesn't stick to the viewport. You can see this on other browsers if you specify overflow-x: hidden both in the body and the html.
|
|
Reporter | |
Comment 4•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Isn't that what I said in bug 1560237 comment 1?
If you mix them, you really have two scrolling boxes (the viewport, and the <body>), and thus sticky, which only works on the closest ancestor, doesn't stick to the viewport. You can see this on other browsers if you specify overflow-x: hidden both in the body and the html.
Yeah, pretty much similar. but the case in comment 2 is a bit different, it's using different properties, overflow-x and overscroll-behavior-x. In this case, the sticky element seems to work as expected on Chrome. I don't know why.
|
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 5•5 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
Yeah, pretty much similar. but the case in comment 2 is a bit different, it's using different properties, overflow-x and overscroll-behavior-x. In this case, the sticky element seems to work as expected on Chrome. I don't know why.
See -> https://bugs.chromium.org/p/chromium/issues/detail?id=954423
I think what you are seeing *could be due to a current chrome bug where they only lift the overscroll properties from the body. Meaning, that overscroll-behavior-x: none; set to html doesn't even effect their root scroller. But when you swap that style declaration over to the body, it actually enables the property and inhibits overscroll on their root scroller.
|
|
||
Comment 6•5 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
|
|
Reporter | |
Comment 7•5 years ago
|
||
Thank for the info. The video makes me understand what's wrong there, I am now empathizing with them. :)
|
||
Updated•2 years ago
|
Description
•