Invalidate the page state when restoring WebUIs

components/sessions/content/content_serialized_navigation_driver.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "components/sessions/content/content_serialized_navigation_driver.h"
 
 #include "base/memory/singleton.h"
 #include "build/build_config.h"
 #include "components/sessions/core/serialized_navigation_entry.h"
 #include "content/public/common/page_state.h"
@@ skipping 85 matching lines @@
 
 void ContentSerializedNavigationDriver::Sanitize(
     SerializedNavigationEntry* navigation) const {
   content::Referrer old_referrer(
       navigation->referrer_url_,
       static_cast<blink::WebReferrerPolicy>(navigation->referrer_policy_));
   content::Referrer new_referrer =
       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.
   if (navigation->referrer_url_ != new_referrer.url) {
     navigation->referrer_url_ = GURL();
     navigation->referrer_policy_ = GetDefaultReferrerPolicy();
     navigation->encoded_page_state_ =
         StripReferrerFromPageState(navigation->encoded_page_state_);
   }
 
@@ skipping 11 matching lines @@
 }
 
 std::string ContentSerializedNavigationDriver::StripReferrerFromPageState(
       const std::string& page_state) const {
   return content::PageState::CreateFromEncodedData(page_state)
       .RemoveReferrer()
       .ToEncodedData();
 }
 
 }  // namespace sessions