Bug 63777 – location.replace with a hash change does not update the history entry

• Status: RESOLVED
• Resolution: FIXED
• Component: History

[Mihai Parparita]

location.replace with a hash change does not update the history entry

[Mihai Parparita]

Created attachment 99411 [details]
Patch

[Mihai Parparita]

The test case passes in Firefox, I will verify the behavior in IE shortly.

Fixes http://crbug.com/86000 and http://crbug.com/78485.

[Mihai Parparita]

*** Bug 57979 has been marked as a duplicate of this bug. ***

[Mihai Parparita]

*** Bug 59195 has been marked as a duplicate of this bug. ***

[Mihai Parparita]

IE behaves the same as Firefox.

[WebKit Review Bot]

Comment on attachment 99411 [details]
Patch

Attachment 99411 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/8959920

New failing tests:
fast/loader/crash-replacing-location-before-load.html

[WebKit Review Bot]

Created attachment 99424 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: Chromium  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Mihai Parparita]

Created attachment 99426 [details]
Patch

[Darin Fisher (:fishd, Google)]

Comment on attachment 99426 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=99426&action=review

R=me

> Source/WebCore/loader/HistoryController.cpp:514
> +    if (m_currentItem) {

I notice that recursiveUpdateForSameDocumentNavigation() can assign m_currentItem if
there is a non-null m_provisionalItem.  I just want to make sure that it makes sense
to work with m_currentItem after calling recursiveUpdateForSameDocumentNavigation()
versus before.

[Mihai Parparita]

(In reply to comment #9)
> I notice that recursiveUpdateForSameDocumentNavigation() can assign m_currentItem if
> there is a non-null m_provisionalItem.  I just want to make sure that it makes sense
> to work with m_currentItem after calling recursiveUpdateForSameDocumentNavigation()
> versus before.

I think so, it seems reasonable to want the the current history item to reflect the current URL, instead of having those changes be clobbered when a provisional load is committed.

[WebKit Review Bot]

Comment on attachment 99426 [details]
Patch

Clearing flags on attachment: 99426

Committed r90281: <http://trac.webkit.org/changeset/90281>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.