Bug 5991 - [CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/By/ingElement)
Summary: [CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML DOM (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: https://drafts.csswg.org/cssom-view/
Keywords: HasReduction
: 106133 121876 (view as bug list)
Depends on: 171215
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-07 13:28 PST by Dave Hyatt
Modified: 2017-07-18 08:29 PDT (History)
20 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Hyatt 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.
Comment 1 Dave Hyatt 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.
Comment 2 Dave Hyatt 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.
Comment 3 Dave Hyatt 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.
Comment 4 Eric Seidel 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.
Comment 5 Joost de Valk (AlthA) 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.
Comment 6 Joost de Valk (AlthA) 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...
Comment 7 Joost de Valk (AlthA) 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.
Comment 9 Gérard Talbot 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
Comment 10 Ojan Vafai 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
Comment 11 Diego Perini 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.
Comment 12 Frédéric Wang (:fredw) 2017-04-21 01:58:38 PDT
*** Bug 121876 has been marked as a duplicate of this bug. ***
Comment 13 Frédéric Wang (:fredw) 2017-04-21 01:59:08 PDT
*** Bug 106133 has been marked as a duplicate of this bug. ***
Comment 14 Frédéric Wang (:fredw) 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
Comment 15 Frédéric Wang (:fredw) 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.
Comment 16 Frédéric Wang (:fredw) 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
Comment 17 Rick Byers 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 ;-)
Comment 18 Diego Perini 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 !