[Webkit-unassigned] [Bug 48812] FrameLoader::checkLoadCompleteForThisFrame uses wrong history item

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 3 12:41:13 PDT 2010


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





--- Comment #9 from Charles Reis <creis at chromium.org>  2010-11-03 12:41:13 PST ---
(In reply to comment #8)
> > Is there a way to tell the browser to go back twice quickly without waiting for the first navigation to 
> > commit?  Or to force the first back navigation to cancel?
> 
> You may be able to do that in a separate window. LayoutTestController.setCanOpenWindows() enables window.open() in DumpRenderTree.

Thanks.  That's a good idea, but I can't seem to get it to cancel the first back navigation with the second one-- it always finishes the first navigation before attempting the second, even if there's a slow response from the server.  For reference, I'm using the new window to tell the first window to go back twice, using some tricks with history.goBack() and setTimeout.

In fact, I'm not even able to manually repro the bug in Chromium's test_shell (since it's not possible to hold down a "back" keyboard shortcut and clicking back repeatedly doesn't trigger it).  It's definitely present in Chromium, though, since the navigation messages come in asynchronously from another process.

As for the fix, it looks like we need to distinguish between two cases: If the navigation is just canceled using Stop or an equivalent, we're currently doing the right thing by going back to the last committed item.  If the navigation is canceled because a new one is in progress, then we should not be going back to the last committed item.  Ideally, we'd just leave the backForward() alone.  (If that new navigation cancels, the other logic will kick in and send us back to the last committed item.)

Perhaps a better fix would involve setting shouldReset to false if the backForward() current item is different than the URL being canceled (i.e., pdl->requestURL())?

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



More information about the webkit-unassigned mailing list