NEW Bug 5991
[CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/By/ingElement) 
https://bugs.webkit.org/show_bug.cgi?id=5991
Summary [CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/...
Dave Hyatt
Reported 2005-12-07 13:28:00 PST
In an earlier fix, I made overflow on the root element actually apply to the document. I believe that scrollLeft/Top presumably need to scroll the document as well (rather than just scrolling some corresponding layer). In quirks mode this may also be true for the body element as well. This bug is here to investigate the issue.
Attachments
Testcase for IE strict mode (346 bytes, text/html)
2006-02-05 02:11 PST, Joost de Valk (AlthA) 		no flags
Details
Testcase for IE quirks mode (228 bytes, text/html)
2006-02-05 02:14 PST, Joost de Valk (AlthA) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Dave Hyatt
Comment 1 2005-12-07 13:28:32 PST
Need some test cases of what WinIE does in quirks and strict mode with scrollLeft/Top on both the <body> and <html> elements.
Dave Hyatt
Comment 2 2005-12-07 13:29:19 PST
See also: http://bugs.kde.org/show_bug.cgi?id=99380 which seems to apply a partial fix, but oddly only deals with setting and not with getting.
Dave Hyatt
Comment 3 2005-12-07 13:31:40 PST
Note that we do this already on the <body> element. We just need to do it for root elements as well.
Eric Seidel (no email)
Comment 4 2005-12-28 00:43:16 PST
Either vicki or adele were working on scrolling issues like this very recently. We'll need a reduced test case for this one.
Joost de Valk (AlthA)
Comment 5 2006-02-05 02:11:41 PST
Created attachment 6265 [details] Testcase for IE strict mode In IE, this scrolls down 100 pixels. Note that, when the DTD is left out, and IE goes in quirks mode, this doesn't work.
Joost de Valk (AlthA)
Comment 6 2006-02-05 02:14:12 PST
Created attachment 6266 [details] Testcase for IE quirks mode Adding a html 4 DTD to thise one, forcing IE in strict mode, makes it not work anymore...
Joost de Valk (AlthA)
Comment 7 2006-02-05 02:25:21 PST
Ok the comment on the first testcase was wrong, it's like this: Strict Quirks document.body.scrollTop - x document.documentElement.scrollTop x x The fact that document.documentElement.scrollTop works in IE is disputed by: http://www.quirksmode.org/viewport/compatibility.html but both me and Alexey found it to be working when testing with the above testcases.
Gérard Talbot (no longer involved)
Comment 9 2006-04-04 21:37:33 PDT
> Need some test cases of what WinIE does in quirks and strict mode with > scrollLeft/Top on both the > <body> and <html> elements. For standards compliant rendering mode (document.compatMode == "CSS1Compat"), if you have access to WinIE6, then you can try these 2 pages: http://www.gtalbot.org/BugzillaSection/Bug189308_ScrollEvent.html http://www.gtalbot.org/DHTMLSection/WindowEventsMSIE6.html
Ojan Vafai
Comment 10 2010-08-12 15:47:19 PDT
This has now been added to http://dev.w3.org/csswg/cssom-view/#scroll-attributes and WebKit does not match the spec. See discussion: http://lists.w3.org/Archives/Public/www-style/2009Oct/0314.html
Diego Perini
Comment 11 2014-09-19 05:59:48 PDT
The following code may be useful to find out which is the element in charge of scrolling the viewport: function getScrollingElement() { var d = document; return d.documentElement.scrollHeight > d.body.scrollHeight && d.compatMode.indexOf('CSS1') == 0 ? d.documentElement : d.body; } it must be invoked before performing the actual scroll operation instead of during onload or DOMContentLoaded since the content may change later. See here for a cross browser example using the above code: https://dl.dropboxusercontent.com/u/598365/scrollTo/scrollTo.html This code will work when the bug will be fixed as explained in W3C CSSOM View specifications.
Frédéric Wang (:fredw)
Comment 12 2017-04-21 01:58:38 PDT
*** Bug 121876 has been marked as a duplicate of this bug. ***
Frédéric Wang (:fredw)
Comment 13 2017-04-21 01:59:08 PDT
*** Bug 106133 has been marked as a duplicate of this bug. ***
Frédéric Wang (:fredw)
Comment 14 2017-04-24 01:41:51 PDT
The issue with scrollTop/scrollLeft is actually a specific case of a general problem with that WebKit does not align on the CSSOM View Module [1], especially for quirks VS non-quirks modes. Hence I am renaming this bug to make it more explicit. There are some tests in the W3C test suite [2] that we should probably import. In particular, the following tests are relevant: * scrollingElement.html * scrolling-quirks-vs-nonquirks.html Chromium has a scrollLeftTopInterop runtime flag to implement the behavior specified in CSSOM View. Comparing Blink and WebKit code (dom/Element.cpp and dom/Document.cpp), I essentially see the following differences: 1) Chromium implements the spec's "If document is not the active document" for scrollLeft/Top (getting & setting), scrollTo/By and scrollWidth/Height. WebKit does not do that but I think it would be safe to change it without breaking existing page. I am not exactly sure how to test it, though. 2) Chromium implements the spec's behavior of scrollingElement, which can be be the root, the body or null. WebKit always returns the body (bug 143609). 3) For scroll(Left/Top/Width/Height/To/By), Chromium has specific cases to perform the operation on viewport when the element is the scrollingElement, corresponding to the "element == body or root" cases in the spec. WebKit always performs the operation on the element itself. I believe it would not be hard to import code from Chromium into WebKit in order to implement the standard behavior. The main issue I see is that it may break existing pages. AFAIK, Google still has not enabled the scrollLeftTopInterop flag for that reason [3]. @Rick: Can you please indicate the latest update on this? [1] https://drafts.csswg.org/cssom-view/ [2] http://w3c-test.org/cssom-view/ [3] https://bugs.chromium.org/p/chromium/issues/detail?id=157855#c110
Frédéric Wang (:fredw)
Comment 15 2017-05-01 02:46:50 PDT
(In reply to Frédéric Wang (:fredw) from comment #14) > There are some tests in the W3C test suite [2] that we should probably > import. In particular, the following tests are relevant: > * scrollingElement.html > * scrolling-quirks-vs-nonquirks.html These tests have been imported in https://trac.webkit.org/changeset/215726/ and they currently fail.
Frédéric Wang (:fredw)
Comment 16 2017-07-14 08:08:00 PDT
(In reply to Frédéric Wang (:fredw) from comment #14) > @Rick: Can you please indicate the latest update on this? Replying to myself. Chromium is considering shipping the standard behavior for document.scrollingElement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4
Rick Byers
Comment 17 2017-07-14 09:42:00 PDT
Sorry I missed the above question for me. Not only are we "considering" it, it's shipping in Chrome 61 (https://crbug.com/157855), current in "dev" release. We've had to do one pretty ugly hack for non-standard 'mousewheel' listeners to make this possible (https://bugs.chromium.org/p/chromium/issues/detail?id=501568#c35), but at least it has the side benefit of being a substantial scroll performance win on impacted sites. If we can pull it off then IMHO it will be worth it. For WebKit I suggest waiting until we know the fall-out of this Chrome change reaching all our users (roughly mid-september assuming we don't hit an issue severe enough to cause us to delay). Then we'll share a summary of the results more broadly and circle back here. I hope that we'll be able to get consensus across all browsers here one way or another ;-)
Diego Perini
Comment 18 2017-07-14 14:41:07 PDT
Rick, I have been looking forward for this change hoping it would happen one day ! About browser consensus I believe Webkit was the only browser missing a correct implementation of the standard behavior as recommended by the W3C specifications where the document scrollingElement should be the root element (documentElement) and not the body element as it has been for Webkit until now. It is a great advance towards improved browser convergence. Nowadays very few people show interest into this important area. My fix for this to bridge the transition could still be of help with testing: https://gist.github.com/dperini/ac3d921d6a08f10fd10e Patience is a virtue, thank you for the efforts and the achievements. Have fun !
Simon Pieters (:zcorpan)
Comment 19 2017-12-20 00:03:21 PST
To follow up on comment 17, I think this has shipped in Chrome for a few versions, correct Rick Byers?
Rick Byers
Comment 20 2018-01-25 14:25:24 PST
Sorry for the delay. Yes we shipped in Chrome 61 which hit stable in September, and it stuck: https://www.chromestatus.com/features/6386758136627200. We did find a few impacted sites, and do have that one silly mousewheel hack, but the fallout has been quite minimal and mostly just a few semi-popular libraries being updated (less pain than I expected). See the most recent bugs blocked on https://crbug.com/157855 for details. I'd love to see WebKit update as well. With Chrome and Firefox now following the spec here, there's of course increasing risk that new code will be broken specifically on Safari - so the compat tradeoff for WebKit will shift over time.
Frédéric Wang (:fredw)
Comment 21 2018-01-30 08:23:42 PST
(In reply to Rick Byers from comment #20) > I'd love to see WebKit update as well. With Chrome and Firefox now > following the spec here, there's of course increasing risk that new code > will be broken specifically on Safari - so the compat tradeoff for WebKit > will shift over time. For the record, I started to work on this recently and just announced it on webkit-dev if you want to continue discussion there: https://lists.webkit.org/pipermail/webkit-dev/2018-January/029857.html
Brent Fulgham
Comment 22 2018-03-16 09:52:34 PDT
<rdar://problem/22296476>
Simon Fraser (smfr)
Comment 23 2021-10-09 12:17:29 PDT
What's the current status of this work?
Note You need to log in before you can comment on or make changes to this bug.