59912005-12-07 13:28:00 -0800[CSSOM View] Implement standard behavior for scroll(Left/Top/Width/Height/To/By/ingElement)2018-09-10 01:29:56 -0700111UnclassifiedWebKitDOM420+MacintoshOS X 10.4NEWhttps://drafts.csswg.org/cssom-view/HasReduction, InRadarP2Normal---1616121822891822901822921880451436091712151820531822301822411822871894721hyattwebkit-unassignedadeleapbfulghambrowserbugs2cdumezclaude.pachedarindbatesdiego.perinidvoytenkofred.wangianjfernandezjoostmathiasplaymobilrbuisrbyersrmondellosyoichitonikitoovince.t.malonezcorpanoldest_to_newest256680hyatt2005-12-07 13:28:00 -0800In 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.256691hyatt2005-12-07 13:28:32 -0800Need some test cases of what WinIE does in quirks and strict mode with scrollLeft/Top on both the
<body> and <html> elements.
256702hyatt2005-12-07 13:29:19 -0800See 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.
256713hyatt2005-12-07 13:31:40 -0800Note that we do this already on the <body> element. We just need to do it for root elements as well.269384eric2005-12-28 00:43:16 -0800Either vicki or adele were working on scrolling issues like this very recently. We'll need a reduced test case
for this one.3142556265joost2006-02-05 02:11:41 -0800Created attachment 6265
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.3142666266joost2006-02-05 02:14:12 -0800Created attachment 6266
Testcase for IE quirks mode
Adding a html 4 DTD to thise one, forcing IE in strict mode, makes it not work anymore...314277joost2006-02-05 02:25:21 -0800Ok 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.314338ap2006-02-05 02:34:13 -0800Some more tests:
http://www.xs4all.nl/~ppk/js/doctype_on.html
http://www.xs4all.nl/~ppk/js/doctype_off.html385809browserbugs22006-04-04 21:37:33 -0700> 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.html26404510ojan2010-08-12 15:47:19 -0700This 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.html103611611diego.perini2014-09-19 05:59:48 -0700
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.129956112fred.wang2017-04-21 01:58:38 -0700*** Bug 121876 has been marked as a duplicate of this bug. ***129956313fred.wang2017-04-21 01:59:08 -0700*** Bug 106133 has been marked as a duplicate of this bug. ***130045214fred.wang2017-04-24 01:41:51 -0700The 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#c110130321215fred.wang2017-05-01 02:46:50 -0700(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.132875116fred.wang2017-07-14 08:08:00 -0700(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/X64Sg16RhT4132881317rbyers2017-07-14 09:42:00 -0700Sorry 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 ;-)132901518diego.perini2017-07-14 14:41:07 -0700Rick,
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 !138355719zcorpan2017-12-20 00:03:21 -0800To follow up on comment 17, I think this has shipped in Chrome for a few versions, correct Rick Byers?139329020rbyers2018-01-25 14:25:24 -0800Sorry 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.139455721fred.wang2018-01-30 08:23:42 -0800(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.html140701222bfulgham2018-03-16 09:52:34 -0700<rdar://problem/22296476>62652006-02-05 02:11:41 -08002006-02-05 02:11:41 -0800Testcase for IE strict modescrollTopStrict.htmltext/html346joostPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIiAKICAgICJodHRwOi8vd3d3LnczLm9yZy9UUi9odG1sNC9sb29zZS5kdGQiPgo8aHRtbD4K
PGJvZHkgb25Mb2FkPSJqYXZhc2NyaXB0OmRvY3VtZW50LmRvY3VtZW50RWxlbWVudC5zY3JvbGxU
b3AgPSAxMDA7Ij4KCjxici8+Cjxici8+Cjxici8+CjEKCjxici8+Cjxici8+Cjxici8+CjIKCjxi
ci8+Cjxici8+Cjxici8+CjMKCjxici8+Cjxici8+Cjxici8+CjQKCjxici8+Cjxici8+Cjxici8+
CjUKCjxici8+Cjxici8+Cjxici8+CjYKCjxici8+Cjxici8+Cjxici8+CjcKCjwvYm9keT4KPC9o
dG1sPg==
62662006-02-05 02:14:12 -08002006-02-05 02:14:12 -0800Testcase for IE quirks modescrollTopQuirks.htmltext/html228joostPGh0bWw+Cjxib2R5IG9uTG9hZD0iamF2YXNjcmlwdDpkb2N1bWVudC5ib2R5LnNjcm9sbFRvcCA9
IDEwMDsiPgoKPGJyLz4KPGJyLz4KPGJyLz4KMQoKPGJyLz4KPGJyLz4KPGJyLz4KMgoKPGJyLz4K
PGJyLz4KPGJyLz4KMwoKPGJyLz4KPGJyLz4KPGJyLz4KNAoKPGJyLz4KPGJyLz4KPGJyLz4KNQoK
PGJyLz4KPGJyLz4KPGJyLz4KNgoKPGJyLz4KPGJyLz4KPGJyLz4KNwoKPC9ib2R5Pgo8L2h0bWw+