Attaching expected video for reference

Deleted: Expected_Scrolling.mp4 16.7 MB

Expected_Scrolling.mp4 16.7 MB Download

After you press "Tab" at the status tray, focus is still in the native UI.
You have to press "Tab" one more time to focus EULA.

Note I just landed a CL (https://chromium-review.googlesource.com/710738) to replace Eula iframe with webview. And maybe affect this. One thing worth trying is to add a tabIndex attribute to the webview tags and see that helps.

Update: adding tabindex="0" could help. It will focus first on frame, and not able to scroll contents. Another tab will do the scroll. And another tab will move the focus to the next one. The expected behavior seems that it doesn't need a second tab for scrolling contents?

Ping as this has been open for some time as a P1.  Did we confirm the CL impact per #4?  Let's untag as RBS if possible.

Confirmed that CL in #4 brings this bug. We need a work around here. The expected behavior is it shouldn't need a second tab to scroll the contents.

I personally think it is not a urgent bug (it happens when user tabs through system tray and then scrolls terms). It doesn't have to be RBS. Anyhow I would start looking.

Okay, removing RBS.  Thx.

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

commit 72ece810c9398440582d98c1162af5779461d30b
Author: Qiang Xu <warx@chromium.org>
Date: Wed Jan 10 00:07:31 2018

cros: fix crosEulaFrame needs second tab for focus

changes:
Currently, we are able to scroll on terms contents when eula screen is
shown, not on focus returned from ash::SystemTray. This CL adds this
ability.

Bug:  777372 
Test: tested on emulator
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ia20617ea43e35fd82cbbd469f08f9eecca3f1b6e
Reviewed-on: https://chromium-review.googlesource.com/853532
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Qiang(Joe) Xu <warx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528178}
[modify] https://crrev.com/72ece810c9398440582d98c1162af5779461d30b/chrome/browser/chromeos/login/ui/webui_login_view.cc
[modify] https://crrev.com/72ece810c9398440582d98c1162af5779461d30b/chrome/browser/resources/chromeos/login/login_shared.js
[modify] https://crrev.com/72ece810c9398440582d98c1162af5779461d30b/chrome/browser/resources/chromeos/login/md_login_shared.js
[modify] https://crrev.com/72ece810c9398440582d98c1162af5779461d30b/chrome/browser/resources/chromeos/login/oobe_screen_eula.js

Probably this is m64 wanted.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

#7, #10 aren't very compelling, esp this late in the cycle (and since we agreed that it's not a blocker).  Is there a workaround?  Using the mouse to scroll?

I am fine we don't merge it. The content is always accessible (the bug just needs one more tab stop). Let me know if fix is desired in m64.

ok, moving to M65