New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 737633 link

Starred by 7 users

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Changing document.body.scrollTop does not affect current scroll position, the value remains unchanged

Reported by sus...@gmail.com, Jun 28 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3141.8 Safari/537.36

Steps to reproduce the problem:
Created a JSFiddle for this problem: https://jsfiddle.net/mmvaouLv/

1. Open any web page long enough to have a vertical scrollbar
2. Open console and type document.body.scrollTop = 100
3. Check the current value of document.body.scrollTop

What is the expected behavior?
Scroll position should be changed
document.body.scrollTop should be changed

What went wrong?
Scroll position remains the same
document.body.scrollTop remains the same

Did this work before? Yes 60.0.3112.40

Chrome version: 61.0.3141.8  Channel: dev
OS Version: 8.1
Flash Version: 

Tested on 60.0.3112.40 and previous releases, it worked fine
 

Comment 1 by sus...@gmail.com, Jun 28 2017

I have a screen capture extension, that do manual scrolling while capturing. I started getting reports from users, that scrolling does not work, so I did a research of this problem and found this issue.
Labels: Needs-Triage-M61

Comment 3 by woxxom@gmail.com, Jun 29 2017

Per-snapshot bisect: 481206 (good) - 481213 (bad), 61.0.3138.0
https://chromium.googlesource.com/chromium/src/+log/b2e10129..31c39d8d?pretty=fuller
Suspecting one of the two CL:
  r481208 "Enable scrollTopLeftInterop by default"
  r481209 "Force rootScroller to create composited scroll layers"
Cc: msrchandra@chromium.org
Components: Blink>JavaScript
Labels: hasbisect-per-revision M-61 OS-Linux OS-Mac
Owner: dtapu...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Latest Dev# 61.0.3141.7 on Windows, Mac and Linux.
This is a Regression issue in M61 builds. Below is the regression info --
Chrome Good Build -- 61.0.3137.0 (481056).
Chrome Bad  Build -- 61.0.3138.0 (481386).
You are probably looking for a change made after 481206 (known good), but no later than 481208 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/b2e101299180938b571c5779f11105b767c0e70b..4cef659a8009c5cb4f5708336ae37654d23653b3

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/4cef659a8009c5cb4f5708336ae37654d23653b3

@dtapuska -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.
Status: WontFix (was: Assigned)
This is done on purpose. To support interop with other browsers the scrolling element has become the documentElement in standards mode. In some cases is it the body element in quirks mode.

See the intent to ship here: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/X64Sg16RhT4/6ZiW7Dt8CAAJ

Really you should be using document.scrollingElement to be told what the scrolling element is. This attribute was added for interop ability.

Can you provide any context in where you are encountering this? If it is just code that you are writing then that is fine. But if you are encountering this in a widely used library then we'd like to do some analysis. 

Comment 6 by hau...@pusher.com, Jul 5 2017

Thanks for the quick response! This is just in code we're writing, so we can use `document.scrollingElement`.

Cheers!
 Issue 739332  has been merged into this issue.
 Issue 769438  has been merged into this issue.
 Issue 769765  has been merged into this issue.
 Issue 770192  has been merged into this issue.
 Issue 770564  has been merged into this issue.

Sign in to add a comment