[Webkit-unassigned] [Bug 52819] Crash in WebCore::HistoryController::itemsAreClones

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=52819





--- Comment #15 from Charles Reis <creis at chromium.org>  2011-02-02 13:43:48 PST ---
(In reply to comment #14)
> queueBackNavigation is the layout test specific method for requesting a back navigation.  that will wait until the page is fully loaded before processing the back navigation.  maybe that is related to why this isn't reproducible?

Actually, it's much more subtle!  It turns out history.back() does get to recursiveSetProvisionalItem, just like the back button.  It even has a memory error, but it happens not to crash.

We already figured out that we crash when we hit the back button because we delete fromItem after calling itemsAreClones (on the m_provisionalItem = item line, since fromItem and m_provisionalItem are the same in this case).  On the recursive call, fromItem is 0-- boom.

If we call history.back() instead, we delete that item *before* we get to itemsAreClones, back in HistoryController::goToItem() (when we call setGlobalHistoryItem).  Even though we're still using a deleted pointer in that case, we don't happen to crash.  Instead, itemsAreClones returns false when it notices fromItem doesn't have any children.  This is still bad, because it doesn't update the provisional item.

Either way, I noticed a flaw in my expectations file-- after going back twice, we should be at the original HistoryItem, not the second one.

All this boils down to the fact that we're not clearing the provisional item after getting to an error page (like the confirm form resubmission page in this test).

Question: what's the intended behavior for an error page?  Should we commit the provisional item and make it the last committed item?  Or should we cancel the provisional item and act like we didn't go anywhere?  (More specifically in this case, if I get an error page when I click back, what's supposed to happen if I click back again?)  I'm guessing we want to commit it, but that isn't currently happening.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.