So far, no repro on my end... 

Tested the same on win8.1 chrome version 54.0.2796.2 on zooming 150% and scrolling twice tried to pan the map with mouse - observed that there is no page scrolling observed

Please find the screencast

Could you please let us know if this is still reproducible. If yes please mention the chrome version details

It looks like we're anchoring to something inside the map and that changes when we try to pan, resulting in an incorrect adjustment.

Discussing potential solutions with skobes but we probably need a way to disable scroll anchoring when a layout is caused by a user-gesture. 

Rough ideas:

- somehow disable anchoring during a user's drag gesture, without also disabling it during native touch scrolls
- make findAnchor skip elements whose transform has recently(?) been updated
- don't pick anchors inside transformed elements at all (big hammer)

Sami, does the renderer scheduler currently know when we're doing a drag gesture?

I think all of these proposals would break scroll anchoring for some subset of JS scrollers, wouldn't they? That's probably okay, but we'd want to be aware we're doing it.

Disabling for script-handled drag gestures would mean we don't get anchoring while the JS scroller is being scrolled (but it would still get anchoring when the user is not scrolling it).

Disabling for transforms would disable scroll anchoring for JS scrollers that use transforms, but not for those that simply change the scroll offset programmatically.  

I think it may be tricky to find a heuristic to classify script-handled drag gestures for which we want to disable scroll anchoring.

For non-touch, it may suffice to query the active button state which tells us whether a user is clicking/interacting with the page. 

For touch, we need to know whether the script prevent defaults while the user is interacting with the page. This is tricky because we need to find a way to cache this information and a single mousemove event (peventing defalt) doesn't correspond to the layout where we are making a decision of whether or not to apply scroll anchoring.

Per today's meeting the plan is to keep track of whether the user is doing a "non-scrolling drag".  On desktop, this is when the mouse button is down; on mobile, we will enter this state when a touchmove is preventDefault'ed, and exit on touchend.  We will suppress scroll anchoring for layouts that occur during this state, and for the first layout following the exit.

This increases the number of web compat hacks we are adding to the scroll anchoring algorithm, which is concerning.  A path to reducing these in the long term is:

1. Add an API to exclude portions of the DOM from anchor selection, possibly reusing overflow-anchor.
2. Evangelize the use of this API and/or the opt-out to reduce websites' reliance on the hacks we have added.
3. Remove the hacks (non-scrolling drag suppression, bounce suppression, total adjustment limit, position:absolute exclusions).

I wonder if any of the use cases the Blink scheduler detects would be useful here: https://cs.chromium.org/chromium/src/components/scheduler/renderer/renderer_scheduler_impl.h?rcl=0&l=47

Fixed by SANACLAP (r413010).