+OOBE devs: I'm trying to determine if it's the OOBE page that needs to be fixed or if our heuristic for scrollbar themeing is wrong. Is src/chrome/browser/resources/chromeos/login/oobe_screen_terms_of_service.html the place to be looking? Is there an easy way to debug (using DevTools?) the OOBE pages?

alemate@ has done a lot more work on OOBE ui, but you can open dev tools by running CrOS on linux with --remote-debugging-port=9222 and --login-manager. Then in desktop chrome go to localhost:9222 and pick the oobe page.

In the new ChromeOS OOBE design EULA is displayed here: https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_eula.html . Actual ToS document is loaded in an iframe. The styling for iframe scrollbar is here https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_eula.css . Some of the scroll bar styling is possible only from the iframe itself, so this is left "as is".

The document itself is dynamically downloaded from Google (with fallback if Google servers are unavailable).


I don't know how OOBE EULA screen is implemented for the desktop. But if you can suggest similar styling, that would be nice.

 Issue 709339  has been merged into this issue.

Thanks for the help. Re#4, I managed to get the OOBE flow up and running but I don't seem to get a EULA screen. I get the "Welcome!" screen, followed by "Connect to Network" and then the "Login" prompt. Any idea what I'm missing?

reproduced on Chrome Version: 59.0.3071.15 /ChromeOS:9460.5.0

Ping: jdufault@ or alemate@ - Should be an easy fix if I can get a custom build to launch into the terms page.

Maybe alemate@ knows a faster method, but the easiest way I know of to show ToS screen is to deploy to device. This[1] is the easiest method to do it.

You can sort of get there locally by opening up dev-tools and running `Oobe.showScreen({id: SCREEN_TERMS_OF_SERVICE})`, but that doesn't actually load ToS contents.

1: https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/building-chromium-browser

Re #9

> Ping: jdufault@ or alemate@ - Should be an easy fix if I can get a custom build to launch into the terms page.


Is this sufficient (see below)?

gn gen out/Release --args="is_debug=false use_goma=true target_os=chromeos is_chrome_branded=true is_official_build=true" && ninja -C out/Release/ -j3000 chrome chrome_sandbox  && (UDD=$HOME/cros-test-user-data-dir-tmp ; rm -rf $HOME/cros-test-user-data-dir-tmp ; mkdir -p $HOME/cros-test-user-data-dir-tmp ; ./out/Release/chrome --login-manager --login-profile=user --user-data-dir=$UDD  --disable-setuid-sandbox --no-sandbox  --remote-debugging-port=9999   )

?

Ah, building official/branded did the trick, thanks. I think I've found the issue, should have a fix shortly.

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

commit f82b1ff2761897b38ae79042810fb0a9f3ff747f
Author: bokan <bokan@chromium.org>
Date: Wed Apr 26 18:17:04 2017

Use dark scrollbar theme for transparent frames.

If the given background color is totally transparent we should default
to using the dark theme since that's the default. ChromeOS OOBE pages,
for example, set an override background color of "TRANSPARENT" which is
#00000000 in RGBA. Our old logic looked only at the RGB bits so it
concluded that the frame had a black background and used white scollbars.

We don't have enough information in Blink to know what theme to use in
this case but falling back to the default theme should be good enough.

BUG= 709978 

Review-Url: https://codereview.chromium.org/2840223002
Cr-Commit-Position: refs/heads/master@{#467382}

[modify] https://crrev.com/f82b1ff2761897b38ae79042810fb0a9f3ff747f/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
[modify] https://crrev.com/f82b1ff2761897b38ae79042810fb0a9f3ff747f/third_party/WebKit/Source/web/tests/ScrollbarsTest.cpp

Ok, this should be fixed now in ToT. Thanks for the help folks!

I'll leave this open until I confirm the fix in a Canary and then we'll need to merge back to 59.

Unfortunately I don't have access to a Canary device, but I've confirmed on ToT. Requesting merge.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

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

commit 115b23c07b6c2794b80190193300c83fa0d8c915
Author: David Bokan <bokan@chromium.org>
Date: Fri Apr 28 22:02:52 2017

Use dark scrollbar theme for transparent frames.

If the given background color is totally transparent we should default
to using the dark theme since that's the default. ChromeOS OOBE pages,
for example, set an override background color of "TRANSPARENT" which is
00000000 in RGBA. Our old logic looked only at the RGB bits so it
concluded that the frame had a black background and used white scollbars.

We don't have enough information in Blink to know what theme to use in
this case but falling back to the default theme should be good enough.

BUG= 709978 

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

Review-Url: https://codereview.chromium.org/2851853003 .
Cr-Commit-Position: refs/branch-heads/3071@{#305}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/115b23c07b6c2794b80190193300c83fa0d8c915/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
[modify] https://crrev.com/115b23c07b6c2794b80190193300c83fa0d8c915/third_party/WebKit/Source/web/tests/ScrollbarsTest.cpp

ChromeOS 9460.25.0 / 59.0.3071.38