| Issue 4684: | Back button loses functionality after refresh with hash links. | |
| 1 person starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : 0.3.154.9
URLs (if applicable) : picasaweb.google.com, mail.google.com, etc.
Other browsers tested: Safari 3.2 (525.26.13)
Safari 3: OK
Firefox 3: OK
IE 7: OK
What steps will reproduce the problem?
1. Navigate through more than one hash link on any page (for example, #a,
#b, #c).
2. Refresh the page (hitting F5 or the button).
3. Hit the back button multiple times.
What is the expected result?
The browser will navigate backward through each hash state (#c, #b, #a,
etc.)
What happens instead?
The browser is stuck in a loop between the last two hash states (#c, #b,
#c, #b, etc.)
Minimal test page:
<html>
<a href="#a">a</a>
<a href="#b">b</a>
<a href="#c">c</a>
</html>
Click on each link, refresh the page, and then hit the back buttons.
|
||||||||||||||||||||
,
Nov 21, 2008
(No comment was entered for this change.)
Status: Untriaged
Cc: m...@chromium.org j...@chromium.org |
|||||||||||||||||||||
,
Nov 21, 2008
Version: 0.4.154.23 (Official Build 5672) Just like you said ... I can reproduce this consistently. Now I'm wondering if this is related to other instances we've seen of tab history navigation errors (such as issue 4601). They have some eerie things in common: * Bouncing back and forth between 2 history entries instead of traversing backwards. * A maximum of 12 duplicate items in tab history (each alternate one actually representing one or the other of the same 2 URLs). |
|||||||||||||||||||||
,
Nov 22, 2008
This turns out to have broken with r2201. Assigning to brettw for the fix.
Status: Assigned
Owner: bre...@chromium.org Labels: -Pri-2 -Area-Misc Pri-1 Area-BrowserBackend Mstone-1.0 Regression |
|||||||||||||||||||||
,
Nov 24, 2008
This problem is because RenderView::UpdateSessionHistory gets the previous state of the URL and then sends it upstream to the browser. This includes the previous reference fragment. When you press reload, the previous state is ...#b and this is sent up. However, it uses the current page ID. WebContents::UpdateState sees the page ID as being the current one, but the URL being the old one. Then it updates the URL with the the "old" one (...#b) when you're reloading ...#c. This seems pretty messed up. If my r2201 regressed this, it's only because the old code was somehow covering this problem up. I think it's a longstanding problem. It's definitely invalid to update the state using the previous URL and the current page ID. It may be good enough for the branch to just not update the URL in WebContents. There will be some brokenness as a result of this weird behavior (not exactly sure what, specifically, it would be something like the form state gets lost), but we've always had this bug. I don't see why that code needs to update the URL (we should already be in sync due to the navigation messages).
Status: Started
|
|||||||||||||||||||||
,
Nov 24, 2008
Fixed in r5942. There is a bunch more brokenness here, but I'll file separate bugs (and it doesn't block beta).
Status: Fixed
|
|||||||||||||||||||||
,
Nov 24, 2008
Fixed in r5942. |
|||||||||||||||||||||
,
Nov 24, 2008
Fixed on branch in r5950 |
|||||||||||||||||||||
,
Dec 03, 2008
Works fine in 0.4.154.31(r6264). -Venkat.
Status: Verified
|
|||||||||||||||||||||
,
Dec 18, 2009
(No comment was entered for this change.)
Labels: -Area-BrowserBackend Area-Internals
|
|||||||||||||||||||||
| ► Sign in to add a comment | |||||||||||||||||||||