Please find the logs & video @ http://go/chrome-androidlogs1/8/908809

Bisect info:

Good Commit: 608012
Bad Commit: 608013

Culprit CL:
https://chromium.googlesource.com/chromium/src/+/b64d0a8c04db08eaa81502868a5802d660030842

Assigned to Hugo.

With my change, scrollable divs became not only tab-focusable but also also "fully" click-focusable. 

Previously, clicking/tapping a scroller did not change :focus or activeElement (see Issue 585413#2).

We only want tabbing (but not clicking) to change "actual focus", right?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d01359aed14ae96dc5d0df4e10b3f063d902750a

commit d01359aed14ae96dc5d0df4e10b3f063d902750a
Author: Hugo Holgersson <hugoh@vewd.com>
Date: Wed Dec 05 09:49:50 2018

KeyboardFocusableScrollers try #2: No click-to-focus scrollers

Background:
My first attempt [1] to implement KeyboardFocusableScrollers
made scrollers click-focusable. This got reported as a
regression in  Issue 908809 .

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1258331.

This happens when HandleMouseFocus() uses SupportsFocus():

Element::SupportsFocus() <---
Element::IsMouseFocusable()
Element::IsFocusable()
MouseEventManager::HandleMouseFocus()
EventHandler::HandleMousePressEvent()

Problem:
After [1], SupportsFocus() and therefore also IsMouseFocusable()
returns true for all scrollable scrollers. If a clicked element
is "mouse focusable", HandleMouseFocus() calls FocusController::
SetFocusedElement(element) which makes |element| the activeElement.
Changing activeElement on clicks is reported as a regression.

Solution:
This CL reverts [1]'s change in SupportFocus() and instead
decouples IsMouseFocusable() and IsKeyboardFocusable().

Now we're back to the old mouse focus semantics: clicking a
scroller does *not* make it the activeElement, does not trigger
:focus CSS and does not target the scroller with a focus-event.
However, tabbing to a scroller *does* all that. That's the
feature of KeyboardFocusableScrollers.

This CL does not add any new tests, instead, it reverts some
of [1]'s test changes so tests again expect that clicking or
tapping a scroller doesn't move focus.

Bug:  585413 ,  908809 
Change-Id: Ia0f41cb2e0bf2c093eb2c6d6fa15af5d00aa69c9
Reviewed-on: https://chromium-review.googlesource.com/c/1354450
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Hugo Holgersson <hugoh@vewd.com>
Cr-Commit-Position: refs/heads/master@{#613920}
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/renderer/core/html/html_element.cc
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/fast/events/middleClickAutoscroll-panIcon-expected.html
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/fast/events/middleClickAutoscroll-panIcon.html
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/platform/linux/fast/overflow/overflow-text-hit-testing-expected.png
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/platform/linux/ietestcenter/css3/bordersbackgrounds/background-attachment-local-scrolling-expected.png
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/platform/mac/fast/overflow/overflow-text-hit-testing-expected.png
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/platform/mac/ietestcenter/css3/bordersbackgrounds/background-attachment-local-scrolling-expected.png
[modify] https://crrev.com/d01359aed14ae96dc5d0df4e10b3f063d902750a/third_party/blink/web_tests/platform/win/fast/overflow/overflow-text-hit-testing-expected.png

As per the steps issue doesn't repro on latest M73, but still repro on M72. Once this issue merged to M72 will recheck. Thanks 

dtapuska@, do you think it's OK to backport to M72?

Since it is an experimental web platform feature I don't think it is necessary to fix in M72 branch. But it is before beta so its really up to you. If you aren't a committer then you need to convince a committer it is necessary because they'll have to land it in branch for you.

I am a committer.

If you don't think it's too late... As M72 becomes beta, I guess I prefer to see if we get any bug reports on "KeyboardFocusableScrollers try #2". We already know that the initial version of KeyboardFocusableScrollers has this  Issue 908809 .

Your change meets the bar and is auto-approved for M72. Please go ahead and merge the CL to branch 3626 manually. Please contact milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls merge you change to M72 branch 3626 ASAP so we can pick it up for next  Dev/Beta release, RC cut on Monday, 12/10 @ 1:00 PM PT. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd0bd009f54becad6c390a186db1a8abc18a62d3

commit fd0bd009f54becad6c390a186db1a8abc18a62d3
Author: Hugo Holgersson <hugoh@vewd.com>
Date: Mon Dec 10 19:06:21 2018

KeyboardFocusableScrollers try #2: No click-to-focus scrollers

Background:
My first attempt [1] to implement KeyboardFocusableScrollers
made scrollers click-focusable. This got reported as a
regression in  Issue 908809 .

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1258331.

This happens when HandleMouseFocus() uses SupportsFocus():

Element::SupportsFocus() <---
Element::IsMouseFocusable()
Element::IsFocusable()
MouseEventManager::HandleMouseFocus()
EventHandler::HandleMousePressEvent()

Problem:
After [1], SupportsFocus() and therefore also IsMouseFocusable()
returns true for all scrollable scrollers. If a clicked element
is "mouse focusable", HandleMouseFocus() calls FocusController::
SetFocusedElement(element) which makes |element| the activeElement.
Changing activeElement on clicks is reported as a regression.

Solution:
This CL reverts [1]'s change in SupportFocus() and instead
decouples IsMouseFocusable() and IsKeyboardFocusable().

Now we're back to the old mouse focus semantics: clicking a
scroller does *not* make it the activeElement, does not trigger
:focus CSS and does not target the scroller with a focus-event.
However, tabbing to a scroller *does* all that. That's the
feature of KeyboardFocusableScrollers.

This CL does not add any new tests, instead, it reverts some
of [1]'s test changes so tests again expect that clicking or
tapping a scroller doesn't move focus.

Bug:  585413 ,  908809 
Change-Id: Ia0f41cb2e0bf2c093eb2c6d6fa15af5d00aa69c9
Reviewed-on: https://chromium-review.googlesource.com/c/1354450
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Hugo Holgersson <hugoh@vewd.com>
Cr-Original-Commit-Position: refs/heads/master@{#613920}(cherry picked from commit d01359aed14ae96dc5d0df4e10b3f063d902750a)
Reviewed-on: https://chromium-review.googlesource.com/c/1370171
Cr-Commit-Position: refs/branch-heads/3626@{#223}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/renderer/core/html/html_element.cc
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/fast/events/middleClickAutoscroll-panIcon-expected.html
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/fast/events/middleClickAutoscroll-panIcon.html
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/platform/linux/fast/overflow/overflow-text-hit-testing-expected.png
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/platform/linux/ietestcenter/css3/bordersbackgrounds/background-attachment-local-scrolling-expected.png
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/platform/mac/fast/overflow/overflow-text-hit-testing-expected.png
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/platform/mac/ietestcenter/css3/bordersbackgrounds/background-attachment-local-scrolling-expected.png
[modify] https://crrev.com/fd0bd009f54becad6c390a186db1a8abc18a62d3/third_party/blink/web_tests/platform/win/fast/overflow/overflow-text-hit-testing-expected.png

As per the steps issue doesn't repro on latest M72. Hence closing this issue. Thanks 

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/fd0bd009f54becad6c390a186db1a8abc18a62d3

Commit: fd0bd009f54becad6c390a186db1a8abc18a62d3
Author: hugoh@vewd.com
Commiter: hugoh@vewd.com
Date: 2018-12-10 19:06:21 +0000 UTC

KeyboardFocusableScrollers try #2: No click-to-focus scrollers

Background:
My first attempt [1] to implement KeyboardFocusableScrollers
made scrollers click-focusable. This got reported as a
regression in  Issue 908809 .

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1258331.

This happens when HandleMouseFocus() uses SupportsFocus():

Element::SupportsFocus() <---
Element::IsMouseFocusable()
Element::IsFocusable()
MouseEventManager::HandleMouseFocus()
EventHandler::HandleMousePressEvent()

Problem:
After [1], SupportsFocus() and therefore also IsMouseFocusable()
returns true for all scrollable scrollers. If a clicked element
is "mouse focusable", HandleMouseFocus() calls FocusController::
SetFocusedElement(element) which makes |element| the activeElement.
Changing activeElement on clicks is reported as a regression.

Solution:
This CL reverts [1]'s change in SupportFocus() and instead
decouples IsMouseFocusable() and IsKeyboardFocusable().

Now we're back to the old mouse focus semantics: clicking a
scroller does *not* make it the activeElement, does not trigger
:focus CSS and does not target the scroller with a focus-event.
However, tabbing to a scroller *does* all that. That's the
feature of KeyboardFocusableScrollers.

This CL does not add any new tests, instead, it reverts some
of [1]'s test changes so tests again expect that clicking or
tapping a scroller doesn't move focus.

Bug:  585413 ,  908809 
Change-Id: Ia0f41cb2e0bf2c093eb2c6d6fa15af5d00aa69c9
Reviewed-on: https://chromium-review.googlesource.com/c/1354450
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Hugo Holgersson <hugoh@vewd.com>
Cr-Original-Commit-Position: refs/heads/master@{#613920}(cherry picked from commit d01359aed14ae96dc5d0df4e10b3f063d902750a)
Reviewed-on: https://chromium-review.googlesource.com/c/1370171
Cr-Commit-Position: refs/branch-heads/3626@{#223}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}