Invalidate the page state when restoring WebUIs

components/sessions/content/content_serialized_navigation_driver.cc

Index: components/sessions/content/content_serialized_navigation_driver.cc
diff --git a/components/sessions/content/content_serialized_navigation_driver.cc b/components/sessions/content/content_serialized_navigation_driver.cc
index a3305a8695311157429112f3677d91fa124daac5..f7af1144fca06da0d4159d10a81b4404e381428d 100644
--- a/components/sessions/content/content_serialized_navigation_driver.cc
+++ b/components/sessions/content/content_serialized_navigation_driver.cc
@@ -103,6 +103,14 @@ void ContentSerializedNavigationDriver::Sanitize(
       content::Referrer::SanitizeForRequest(navigation->virtual_url_,
                                             old_referrer);
 
+  // Clear any WebUI page state so that WebUI pages reloaded rather than
+  // restored from page state. This fixes session restore when WebUI URLs
+  // change.
+  if (navigation->virtual_url_.SchemeIs(content::kChromeUIScheme) &&
+      navigation->original_request_url_.SchemeIs(content::kChromeUIScheme)) {

[Charlie Reis, 2016/09/22 18:59:51]

This seems like it affects too many cases.  For URLs like chrome://about,
chrome://accessibility, chrome://net-internals, etc, we'll lose any scroll
position and form state if we navigate away and come back.  That's a functional
regression that we should avoid.

Is there any way to limit this to the URLs affected, and/or to the cases when
the state is out of date (perhaps by peeking into the PageState)?

[Dan Beam, 2016/09/22 19:37:34]

do those pages set different virtual URLs?  could we check if the origins of the
virtual and original request URL differ?

[calamity, 2016/09/23 05:06:33]

I don't think we can figure out if the page state is out of date.. At least, not
without reintroducing all our profile problems.

How about limiting this to just MD History and Uber (and MD Settings?) URLs?
They already seem to have no proper state restore.

[Charlie Reis, 2016/09/23 06:33:53]

Confirmed that chrome://settings and chrome://history don't seem to preserve any
PageState today (at least, scroll position or form data).

Of course, that seems like a bug to me, and this would prevent us from ever
fixing it (since we have to be able to restore old sessions).  That seems
unfortunate, but I suppose I'm ok with it if you are.  Maybe some day we can
find a more precise way to clear this and then fix the missing PageState problem
for those pages.

+    navigation->encoded_page_state_ = std::string();
+  }
+
   // No need to compare the policy, as it doesn't change during
   // sanitization. If there has been a change, the referrer needs to be
   // stripped from the page state as well.