DescriptionOptions: maintain history entries on the parent frame.
Currently, navigations within the child frame remain attached to the child
frame while it signals the parent to change path and title. This doesn't quite
work because location.replace and history.replaceState affect all back/forward
list entries which reference that frame's history entry, rather than just the
current one.
Chrome is currently inconsistent about which of the two behaviors it
implements. Fix the settings page to not rely on the bug so it is future-proof.
Instead, when embedded, all pushState and replaceState calls are proxied up to
the parent which manages history for the child. The child converts all
pushState calls to replaceState calls locally.
This adds uber.setTitle, uber.replaceState, and uber.pushState calls along with
a popState message to uber_utils.js. When running standalone, they call the
standard equivalents. When running within the uber page, they delegate to the
parent as appropriate.
In doing so, this fixes places where chrome://settings-frame and
chrome://settings do not set the same URL and title the same. Notably on the
search page and treating the default "settings" page as having a path of ""
rather than "settings".
BUG=317614
TEST=Go to chrome://settings. Open 'Manage search engines...'. Press back.
Press refresh. Should stay on search page.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=271538
Patch Set 1 #Patch Set 2 : Unnecessary diff. #
Total comments: 4
Patch Set 3 : Adjust some comments. #Patch Set 4 : More comments (try jobs on previous) #
Total comments: 33
Patch Set 5 : dbeam comments #
Total comments: 4
Patch Set 6 : Fix BrowserOptionsFrameWebUITest #Patch Set 7 : And another couple of those #Patch Set 8 : dbeam comments #Messages
Total messages: 8 (0 generated)
|