Adding client code for new Windows 10 First Run Experience

chrome/common/url_constants.h

Index: chrome/common/url_constants.h
diff --git a/chrome/common/url_constants.h b/chrome/common/url_constants.h
index 3dbafad6d48d1536798fe1ec013916df3a39cf31..d741cbc3d63eae30381dd4c2b0b7feac91d7b3c8 100644
--- a/chrome/common/url_constants.h
+++ b/chrome/common/url_constants.h
@@ -88,6 +88,7 @@ extern const char kChromeUIUserActionsURL[];
 extern const char kChromeUIUserManagerURL[];
 extern const char kChromeUIVersionURL[];
 extern const char kChromeUIWelcomeURL[];
+extern const char kChromeUIWelcomeWin10URL[];

[michaelpg, 2016/10/22 03:19:01]

Wondering if it would be better to just use kChromeUIWelcomeURL
(chrome://welcome) and create the webui depending on the OS.

[Patrick Monette, 2016/10/24 20:49:40]

I don't think we've quite figured out what we're gonna do about the URL when we
start using it (and the chrome://welcome-win10 is more of a placeholder), but
I've been specifically asked to create a new URL for easier testing by the
designers.

This is also why there's support for key/value query support in
welcome_win10_ui.cc. In theory, the page could just load the right one based
directly on an experiment.

[tmartino, 2016/10/24 21:06:20]

This was my choice so I'll chime in here. The UI testing piece is definitely
part of it, but it's a bit more substantial than that.

I've been doing a rewrite of the code that determines what tabs to show at
startup. A basic overriding principle of the rewrite was to try and cut down on
the number of layers that interact with system state. The old flow is some truly
atrocious spaghetti, making it really hard to determine which levels of
examining/branching on state may preclude which other ones. Restructuring also
allowed me to introduce unit tests to make sure the correct sets of system state
would land on the correct pages (and their correct variants).

I chose to use URLs to modify the welcome and welcome-win10 pages as an
extension of that principle. A lot of the variables we would be switching on for
these variants are also used when deciding whether we want to show the page at
all. We could check these values at construct-time, but that introduces a
second, independent place where we're checking these factors and making
decisions based on them, which IMO is a risk for future bugs and spaghetti code.

[michaelpg, 2016/10/24 21:30:08]

Thanks for the context.

 
 #if BUILDFLAG(ANDROID_JAVA_UI)
 extern const char kChromeUIContextualSearchPromoURL[];
@@ -242,6 +243,7 @@ extern const char kChromeUIUsbInternalsHost[];
 extern const char kChromeUIUserActionsHost[];
 extern const char kChromeUIVersionHost[];
 extern const char kChromeUIWelcomeHost[];
+extern const char kChromeUIWelcomeWin10Host[];
 extern const char kChromeUIWorkersHost[];
 
 #if defined(ENABLE_PRINT_PREVIEW)