MD Settings: enhance restarting Chrome + interacting w/ session restore

content/public/common/url_constants.h

Index: content/public/common/url_constants.h
diff --git a/content/public/common/url_constants.h b/content/public/common/url_constants.h
index 561265d15054dd2f4d9d67ec7b71e2a99bf9e891..fb754329b6184e1d42847f350f8dfcb869d76cfe 100644
--- a/content/public/common/url_constants.h
+++ b/content/public/common/url_constants.h
@@ -36,6 +36,7 @@ CONTENT_EXPORT extern const char kChromeUIBlobInternalsHost[];
 CONTENT_EXPORT extern const char kChromeUIBrowserCrashHost[];
 CONTENT_EXPORT extern const char kChromeUIDinoHost[];
 CONTENT_EXPORT extern const char kChromeUIGpuHost[];
+CONTENT_EXPORT extern const char kChromeUIHelpHost[];

[Charlie Reis, 2017/03/17 17:43:12]

[+jam, nasko, twellington, calamity]

Hmm, these aren't used within content/, so I don't think they belong here. 
There's a rule about classes, structs, and enums in the API guidelines, which I
assume applies to constants as well:

https://www.chromium.org/developers/content-module/content-api
"all classes/structs/enums in the public API must be used by embedders and
content. i.e. if the chrome layer uses a struct but content doesn't know about
it, it doesn't belong in content/public but instead some module that's higher
level."

I see that this was already done for things like kChromeUIHistoryURL in
https://codereview.chromium.org/2676893002 and kChromeUIUberHost in
https://codereview.chromium.org/2355543003 (where I apparently missed it).

jam@: Is this acceptable for constants?  Or is there another way for chrome/ and
components/ to share a constant like this?

[sky, 2017/03/17 19:11:42]

I suspect these constants were added here at least partially for
session_restore. I don't think we should do that. Instead session restore should
callout to the driver so that these constants can be defined in chrome. See
701605 for details on what I mean.

[Dan Beam, 2017/03/17 19:54:07]

FWIW: thestig@ noticed this while I was de-duping these constants as well:
https://codereview.chromium.org/2751653004/
https://bugs.chromium.org/p/chromium/issues/detail?id=701605

I just don't know of any alternatives currently.  Maybe something with
ContentClient?

And yes, I am basically following the same way we fixed session restore for
history:
https://codereview.chromium.org/2355543003

I guess you're now saying you wished that had been done differently?

All webui has a deep, hard dependency on content/ because that's where all of
the machinery for webui lives.  So trying to say "the history page is
chrome-specific" is true, but all the guts still live in content/.  I get that
other embedders use the content/ webui code as well, but do they use the
chrome:// protocol or other kChromeUI* constants?

By the way, I assume you probably saw, but we can't ship the new Material Design
settings page without this CL to fix the session restore behavior.  I'm not
saying the code needs to look like this, but it's a top priority for me to
unblock this.

When I think of code complexity problems in Chrome I think of layering gray
areas like this :(.

 CONTENT_EXPORT extern const char kChromeUIHistogramHost[];
 CONTENT_EXPORT extern const char kChromeUIHistoryHost[];
 #if defined(OS_ANDROID)
@@ -49,6 +50,7 @@ CONTENT_EXPORT extern const char kChromeUINetworkErrorsListingHost[];
 CONTENT_EXPORT extern const char kChromeUINetworkViewCacheHost[];
 CONTENT_EXPORT extern const char kChromeUIResourcesHost[];
 CONTENT_EXPORT extern const char kChromeUIServiceWorkerInternalsHost[];
+CONTENT_EXPORT extern const char kChromeUISettingsHost[];
 CONTENT_EXPORT extern const char kChromeUITracingHost[];
 CONTENT_EXPORT extern const char kChromeUIUberHost[];
 CONTENT_EXPORT extern const char kChromeUIWebRTCInternalsHost[];