I'm also experiencing this on webpages and apps with different steps to reproduce.

Device name: Google Pixel

Chrome application version: Chrome Beta 56.0.2924.23
Operating system: Android 7.1.1; Pixel Build/NMF260

URLs: amazon.com, lifehacker.com, bugs.chromium.org/p/chromium/issues/list
Apps: Amazon Shopping, Newsfold, Relay for Reddit (built-in web browser)

Steps to reproduce:
1. Tap and hold any link on the page 
2. Dismiss the dialog (not applicable for Relay)
3. Attempt to scroll the page up or down 

Expected results: 
Scrolling works
Actual results: 
The link has an orange border (invisible in Relay). Scrolling away from the framed link will always snap back to it.

I noticed this on various sites. I do not get any visual changes in the sites but scrolling snaps to the top after following links.

Google Chrome	56.0.2924.23 (Official Build) beta (32-bit)
Revision	034f1b9f3c64af980d051d007c992dc94882241e-refs/branch-heads/2924@{#437}
OS	Android 7.1.1; Pixel Build/NMF26O
Command Line	--use-mobile-user-agent --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --use-mobile-user-agent --enable-pinch --enable-viewport --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --enable-data-reduction-proxy-lite-page --disable-password-generation --site-per-process --show-autofill-type-predictions --supervised-user-safesites=disabled --enable-features=NTPSaveToOffline,OfflineBookmarks --disable-features=enable-manual-password-generation,enable-password-force-saving --flag-switches-end --enable-instant-extended-api

Made a quick screen recording to show the effect. Notice refreshing the page resets any affect. This is also now 100% reproducible.

https://goo.gl/photos/Y2R93DJE9C4hq8iR8

Steve, David, is this on your radar already? I think this has been happening on Dev for >2 weeks (I first filed in-app feedback on Dec 2nd - on a Pixel with 56.0.2924.10), but I can't find a bug other than this one.

I noticed that this seems to have to do with whether an element has "focus", e.g. after clicking on a link or selecting (by tapping on) an element. The scroll loop can be cleared by deselecting the element, e.g. tapping elsewhere on the page or reloading it.

Maybe related to scroll anchoring?

There have been some changes related to scroll anchoring and focus, it's possible those might have introduced a bug. I can't reproduce myself though on a Nexus 5X, holding down a link doesn't seem to give it focus and I can't find a way to reproduce the orange "focus" ring. Do you know what the difference might be?

Even with a focused text box, which does get the orange ring, I can't reproduce the scroll behavior. I've tried in Chrome 57.0.2950.3 (Dev), 56.0.2924.23 (Beta), and 55.0.2883.91 (Stable) to no avail.

Sorry, in my post above replace "scroll anchoring" with "scroll into view". I don't know about scroll anchoring :)

I think that giving something focus alone isn't enough. Feels a bit like you need a different tab / widget to be active before trying to scroll. The steps described in #1 (and done in the video of #3) and #2 reproduce it for me.

* steps in #0 and #1 .. Sorry :)

I can't repro using steps from any of the reports here. 

According to eseckler@, he can't repro on a N5X either so perhaps it's device specific. skobes@, do you have a Pixel you could try this on?

I tried this on a Pixel with 55.0.2883.91 but was unable to repro either the orange focus rectangle or the scroll jumping.

This seems to be due to another Android app interfering with Chrome via Android's Accessibility features. For me, that's the "Tasker" app. Once disabled, the problem disappears. @other folks experiencing this: Can you try disabling apps listed under accessibility in the Android settings (and then restarting the Chrome app)?

Not sure if this is an issue that's caused by Chrome, Android's accessibility feature, or by a bad third-party app.

Testing with N5X: If I enable any service in Android's Accessibility settings (e.g. "Switch Access"), the problem starts to occur.

OP here. I can confirm that disabling all services under accessibility settings removes the issue. However, this problem must be something very recently introduced as I always have had at least the service enabled for lastpass. 

I can also confirm that enabling one or more services from the the following apps causes the issue: Automagic Premium, LastPass, Light Flow. The common permission they all require is the ”Observe your actions" permission. 

Interesting, there was a scroll perf regression introduced in  issue 666251  that turned out to be related to accessibility, maybe it's related. That was in M54 though.

 Issue 675957  has been merged into this issue.

Attached a trace. Seems that the scroll offset jumps everytimes we handle AccessibilityMsg_Events_ACK. I'll dig deeper.

Deleted: trace_accessibility_scroll.json 11.5 MB

trace_accessibility_scroll.json 11.5 MB View Download

Here's a trace of when the scroll gets reset. It's actually from AccessibilityMsg_PerformAction:

#0  blink::FrameView::updateScrollOffset
#1  0xa7b06d2c in blink::ScrollableArea::scrollOffsetChanged
#2  0xa7b061f0 in blink::ScrollAnimatorCompositorCoordinator::scrollOffsetChanged 
#3  0xa7b0256a in blink::ProgrammaticScrollAnimator::notifyOffsetChanged 
#4  0xa7b02592 in blink::ProgrammaticScrollAnimator::scrollToOffsetWithoutAnimation 
#5  0xa7b06e2e in blink::ScrollableArea::programmaticScrollHelper 
#6  0xa7b06b92 in blink::ScrollableArea::setScrollOffset 
#7  0xa654a02a in blink::RootFrameViewport::distributeScrollBetweenViewports
#8  0xa654a21a in blink::RootFrameViewport::updateScrollOffset
#9  0xa7b06d2c in blink::ScrollableArea::scrollOffsetChanged
#10 0xa7b061f0 in blink::ScrollAnimatorCompositorCoordinator::scrollOffsetChanged
#11 0xa7b0256a in blink::ProgrammaticScrollAnimator::notifyOffsetChanged
#12 0xa7b02592 in blink::ProgrammaticScrollAnimator::scrollToOffsetWithoutAnimation 
#13 0xa7b06e2e in blink::ScrollableArea::programmaticScrollHelper
#14 0xa7b06b92 in blink::ScrollableArea::setScrollOffset
#15 0xa6549e7c in blink::RootFrameViewport::setScrollOffset
#16 0xa654a19e in blink::RootFrameViewport::scrollIntoView
#17 0xa68a0816 in blink::LayoutBox::scrollRectToVisible 
#18 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#19 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#20 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#21 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#22 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#23 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#24 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#25 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#26 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#27 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#28 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#29 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#30 0xa68a0968 in blink::LayoutBox::scrollRectToVisible 
#31 0xa690e60c in blink::LayoutObject::scrollRectToVisible 
#32 0xa624f7c0 in blink::Element::updateFocusAppearance 
#33 0xa61fc424 in blink::Document::setFocusedElement 
#34 0xa6a9b664 in blink::FocusController::setFocusedElement 
#35 0xa624f540 in blink::Element::focus 
#36 0xa537f96c in blink::AXNodeObject::setFocused 
#37 0xa4d3b70c in blink::WebAXObject::setFocused 
#38 0xa3a5fa00 in content::RenderAccessibilityImpl::OnPerformAction

So it looks like for some reason accessibility is constantly setting the focused element which cases it to scroll into view.

maybe related to https://crbug.com/676058?

cc-ing dmazzoni@ for accessibility triage. Dominic, do you have an idea why accessibility might be setting the focus continuously?

I'm seeing lots of reports from the Play Store talking about scrolling issues, so we need to review (and fix) this ASAP.  PTAL dmazzoni@.

FWIW dmazzoni@ is OOO this week.  TE, can we please get an exact bisect on this?

kravula@ - can you try to repro?

We are able to repro this issue with Accessibility-> Switch Access ON option


Chrome Beta :56.0.2924.23
Devices:
Nexus 5X/NMF26V
Samsung Galaxy S7(SM-G930F)/MMB29K

Bisect info:
Good build: 56.0.2924.13
Bad build : 56.0.2924.18

Bisect link :https://chromium.googlesource.com/chromium/src/+log/56.0.2924.13..56.0.2924.18?pretty=fuller&n=10000

Two patches stand out in that range:

"""
commit	7fa77424b02d63b38bb1262471cc4af8e3f54fc0	
author	Dominic Mazzoni <dmazzoni@chromium.org>	Fri Dec 02 20:05:14 2016
Merge to M56: Revert "Android shouldn't fire focus events when the WebView itself isn't focused"

Caused  http://crbug.com/667559  - when clicking on a <select> pop-up and
then returning to the page, focus was being reset to the whole page rather
than back to the select element.

Original changelist: https://chromiumcodereview.appspot.com/2416293002

BUG= 648391 , 667559 
TBR=dtseng@chromium.org

Review-Url: https://codereview.chromium.org/2547903002
Cr-Commit-Position: refs/heads/master@{#435964}
(cherry picked from commit c2607397665f0a0a8e3b16198dbeaae2a9e1e0bb)

Review URL: https://codereview.chromium.org/2546183002 .

Cr-Commit-Position: refs/branch-heads/2924@{#296}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}
"""


And

"""
commit	13ae3f245af2124718f024ae13f328c27c618f09	
author	Koji Ishii <kojii@chromium.org>	Thu Dec 01 08:28:25 2016
committer	Koji Ishii <kojii@chromium.org>	Thu Dec 01 08:31:28 2016
Merge 2924: Avoid updateStyleAndLayoutTree in determineAccessibilityRole

This patch avoids updating layout tree in
AXNodeObject::determineAccessibilityRole().

Element::isFocusable() requires styles to be updated. However, when
layout code calls determineAccessibilityRole(), updating layout tree
should be avoided since it may destroy the calling object.

This patch replaces it to supportsFocus(), since the main purpose is
to give elements with tabIndex explicitly set get some role.

This is a speculative fix.

BUG=590369,  647602 ,  665168 

Review-Url: https://codereview.chromium.org/2532023002
Cr-Commit-Position: refs/heads/master@{#435009}
(cherry picked from commit 338b38e06760302a8010bfea008865f55db4db0c)

Review URL: https://codereview.chromium.org/2542883002 .

Cr-Commit-Position: refs/branch-heads/2924@{#241}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}
"""

I'll try to manually revert each to narrow it down.

The bisect in #25 is wrong, I tried a wider bisect and the problem existed in 56.0.2924.10 and beyond.

I did a fresh bisect and narrowed it down to:

commit fd9566093da77d9413ba61f8be1b6e03daaadf33
Author: dmazzoni <dmazzoni@chromium.org>
Date:   Fri Nov 4 13:40:02 2016 -0700
Android accessibility: automatically focus links
    
Manually reverting from ToT does fix the issue.

And just found  issue 675343  and aelias@ is already on the revert so dup'ing into that.

For future reference, you can exact bisect from Clank prebuilts nowadays, which allowed me to investigate fast.  The command I used is "python clank/tools/bisect-archived-builds.py -a arm --apk chromium -u -o -g 414607 -b 423768"