Closed Bug 1570432 Opened 5 years ago Closed 5 years ago

Element with scrollable overflow changed by scroll-behaviour

Categories

(Core :: Layout: Scrolling and Overflow, defect)

68 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1560237

People

(Reporter: mark.j.fisher, Unassigned)

Details

Attachments

(1 file)

Attached file firefox_scrolltobug.html (deleted) —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Attached is the minimum code required to illustrate the problem. Basically in some circumstances, it is the <body> element which has scrollable overflow, rather than the root <html> element. This means that, for example, window.ScrollTo(0,0) does nothing.

Make sure that the window height is sufficiently small to cause overflow - shouldn't be too much issue as I added a fair amount of placeholder text.

Actual results:

Clicking the button in the attached html document (which executes window.scrollTo(0,0)) does not scroll to the top, as the <body> element has scrollable overflow instead of the root html element. Removing ANY ONE of the following four css rules fixes the issue - i.e it makes the root <html> element have the scrollable overflow rather than the <body> element.

body {
overflow-x: hidden;
}

html {
height: 100%;
}

body {
height: 100%;
}

html {
scroll-behavior: smooth;
}

And the only other css rule I added body { margin: 0;} which is strictly speaking not necessary to reproduce the problem, though without it the issue is confused somewhat as the html has a tiny bit of scrollable overflow too, so there are 2 scrollbars.

Expected results:

I expected the button to make the window scroll to the top, as it does in other browsers. Now you may come back and tell me that the spec is ambiguous and doesn't specify where the scroll overflow should be, and way Firefox does it is just as valid as the other browsers. However, I am fairly certain of one thing at least, and that is that the value of scroll-behaviour should not be changing which elements have scrollable overflow. And also I am fairly sure that the value of overflow-x should not be changing the behaviour of scroll in the y direction.

Component: Untriaged → Layout: Scrolling and Overflow
Product: Firefox → Core

This is a quite confusing test-case. The root cause is a bad interaction between overflow propagation from the body element and scroll-behavior. It all makes sense in the end, bear with me :)

There's this bit of weirdness in CSS where setting overflow on the <body> makes the value apply to the viewport (if there's no overflow set on the root element): https://drafts.csswg.org/css-overflow/#overflow-propagation

Firefox used to propagate scroll-behavior to the viewport from the <body> as well, and thus used to check it the same way it checks overflow on the root element.

By using scroll-behavior: smooth on the root, you stopped the propagation of overflow from the <body>, which means that window.scrollTo would scroll the <html> element rather than the body.

That on its own is not a problem, but since you specify height: 100% on the root and on the body, the body is what ends up generating the scrollbars (as the overflow wasn't propagated).

Anyhow, this was recently fixed in bug 1560237 so scroll-behavior doesn't do that, so your test-case works in nightly and Firefox 69 too.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: