Regression : Unable to scroll the page using mouse wheel for www.artofliving.org.
Reported by
mni...@etouch.net,
Apr 18 2016
|
|||||
Issue descriptionChrome version : 52.0.2711.0 2f8c7fcf0ca7d22c7ef943ea5e3256914bef70f1-refs/heads/master@{#387833} (32/64-bit) Os : All (Windows 7 aero enabled) Url : http://www.artofliving.org/bangalore-ashram Steps : 1. Launch Chrome and navigate to above url. 2. Now try to scroll the page using mouse wheel and observe Actual : Unable to scroll the page using mouse wheel. Expected : Should be able to scroll the page using mouse wheel. This is a regression issue broken in 'M-52' and below is the manual regression and Narrow bisect info: Good build : 52.0.2708.0 Bad build : 52.0.2709.0 Narrow bisect info: https://chromium.googlesource.com/chromium/src/+log/e6a85d3a9d2a71baeb8f091784dc360d8342953d..19cc2c256487d4e70458e519c7c4c231049c68ef?pretty=fuller&n=50 Suspecting : r387224 from Narrow bisect. @bokan : Could you please help to reassign if your change is not the cause for this change.
,
Apr 18 2016
,
Apr 18 2016
adding RB-label as this is recent regression, please change if required. Note: this is working fine in IE 11, Firefox 45.0.1, Safari 5.1.7
,
Apr 18 2016
,
Apr 18 2016
indonesia Pada tanggal 18 Apr 2016 21.57, "bokan@chromium.org via Monorail" < monorail@chromium.org> menulis:
,
Apr 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c6821f17fffc100363aab8ce04c22d6a59b57e33 commit c6821f17fffc100363aab8ce04c22d6a59b57e33 Author: bokan <bokan@chromium.org> Date: Tue Apr 19 21:45:56 2016 Viewport apply scroll should be on the document element not scrollingElement. In r387224 I moved all the viewport scrolling actions be happen from a special apply scroll method installed on the scrollingElement. This turned out to be my misunderstanding of how scrollingElement and viewport scrolling in regards to the DOM tree worked. This caused a bug whenever a page explicitly made the <body> element scrollable as the callback would try to scroll the viewport rather than the <body>. The solution is to install the apply scroll on the document element (<html>). This means that the <body> element will still be considered for scrolling while the scroll bubbles up the DOM. An <html> element never has any overflow of its own, even if it's explicitly marked as overflow: scroll. In most cases, the <body> won't have an overflow clip of its own and so the scroll will defer to the viewport. This is in line with how scrolling worked prior to my change in r387224. Since we no longer query scrollingElement from layout, the failing test expectation (track-word-breaking.html) is no longer tripped by this so I removed the expectation. BUG= 604296 Review URL: https://codereview.chromium.org/1895323002 Cr-Commit-Position: refs/heads/master@{#388320} [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/core/dom/Document.cpp [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/core/dom/Document.h [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/core/page/scrolling/ViewportScrollCallback.cpp [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/core/page/scrolling/ViewportScrollCallback.h [modify] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/web/tests/WebFrameTest.cpp [add] https://crrev.com/c6821f17fffc100363aab8ce04c22d6a59b57e33/third_party/WebKit/Source/web/tests/data/mouse-wheel-overflow-body.html
,
Apr 19 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mni...@etouch.net
, Apr 18 2016