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

Issue 787358 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jan 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

setting "overflow-anchor: none" dynamically on subtree fails to clear existing anchor

Reported by vnexs...@gmail.com, Nov 21 2017

Issue description

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

Steps to reproduce the problem:
attached 2 files (instructions inside)

1) "chrome scroll.htm":
scroll so that the top window border will be above the first square and click on a square below, 

note how the page jumps/scrolls down

2) "chrome2 scroll pageY.htm"
scroll so that the top window border will be above the first square
drag a square from below above the half visible one

page jumps/scrolls and we're also getting wrong e.pageY, note how the dragged square is not near the cursor
(move the mouse really slow to notice separate mousemove events)

What is the expected behavior?
page shouldn't scroll/jump

works ok in Firefox and Edge
doesn't work in Chrome, Chrome Android and Edge beta for Android

What went wrong?
page shouldn't scroll/jump, wrong event.pageY

Did this work before? N/A 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: 10.0
Flash Version:
 
chrome scroll.htm
2.3 KB View Download
chrome2 scroll pageY.htm
4.0 KB View Download

Comment 1 by woxxom@gmail.com, Nov 21 2017

This is the intended behavior of ScrollAnchoring: https://github.com/WICG/ScrollAnchoring/blob/master/explainer.md
You can disable it on the container element via CSS:

.board {
  overflow-anchor: none;
}

Comment 2 by vnexs...@gmail.com, Nov 21 2017

that helps, however without it we're getting wrong value for the event.pageY (see "chrome2 scroll pageY.htm")

Comment 3 by vnexs...@gmail.com, Nov 21 2017

seems that adding 'overflow-anchor: none;' on the fly doesn't help immediately, it's almost like it needs to pass some time for the cache to clear or something. So you have to have it in css on page load, doing $board.css('overflow-anchor', 'none') before the append or even on mousedown won't help; even if you set it with the chrome tools it doesn't help immediately.
Labels: Needs-Triage-M62
Cc: sc00335...@techmahindra.com
Components: -Blink Blink>Scroll
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Triaged-ET M-64 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: skobes@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.94 and on latest canary 64.0.3277.0 using Mac 10.12.6 , Windows 10 and Ubuntu 14.04 with attached HTML files in comment#0.

Bisect Info:
===============
Good Build: 56.0.2895.0
Bad Build: 56.0.2896.0

You are probably looking for a change made after 418714 (known good), but no later than 418715 (first known bad).
  https://chromium.googlesource.com/chromium/src/+log/02a4849687aa7a52e3af8959484f7f8b6b9335cf..73693c4b2eb516e55b700c0317b38d672a0bdb29

Review-Url: https://codereview.chromium.org/2335363003

Suspecting same from changelog.

@skobes: Please confirm the issue and help in re-assigning if this is not related to your change.

Thanks!

Comment 6 by skobes@chromium.org, Nov 27 2017

Labels: -Pri-1 -Type-Bug-Regression Pri-2 Type-Bug
Summary: setting "overflow-anchor: none" dynamically on subtree fails to clear existing anchor (was: page jumps/scrolls and wrong event.pageY when adding element before half visible element )
The value of MouseEvent.pageY is determined before the event handlers are invoked.  If an event handler modifies the scroll position (even indirectly via scroll anchoring), the pageY value isn't automatically adjusted for subsequent handlers of the same event.  I think this explains the behavior you're seeing in "chrome2 scroll pageY.htm".

Failure of applying "overflow-anchor: none" to .board on the fly looks like a bug (though not a P1 regression).

A different workaround is to explicitly restore the scroll position after rearranging the DOM, e.g.:

  var saved_scrollTop = document.scrollingElement.scrollTop;
  hovered.before(plh);
  document.scrollingElement.scrollTop = saved_scrollTop;

Comment 7 by vnexs...@gmail.com, Nov 27 2017

that's pretty much the workaround that I'm using right now, 
if the container doesn't have 'overflow-anchor': none; and the $(window).scrollTop() is different than the saved one I set it back $(window).scrollTop(savedScrolTop)
Status: WontFix (was: Assigned)
As this seems to work as indented I closed it for now.

Sign in to add a comment