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

[bugzilla-daemon at webkit.org]

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


Charles Reis <creis at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fishd at chromium.org




--- Comment #18 from Charles Reis <creis at chromium.org>  2010-11-09 18:22:39 PST ---
(In reply to comment #16)
> You should be able to do with without any LayoutTestController changes if you have a frame that uses a PHP script with a sleep() statement before any bytes are returned (I needed something like that for http://trac.webkit.org/changeset/71368, the inner-most frame is not supposed to go into the committed state before being navigated away from).

Thanks for pointing this out, Mihai!  I was able to get a test working without any new APIs using this technique.

It's worth noting that it also helped me uncover another case (going back twice to the same history item, rather than to different history items), which affects what we need to do to fix it.

(In reply to comment #17)
> Can you use item sequence numbers for this? See http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/loader/HistoryController.cpp&q=itemsequencenumber&exact_package=chromium&l=560.

Yeah, I thought this was the right approach, although there's no way to get the itemSequenceNumber from the DocumentLoader or its ResourceRequest.  As the second part of the test showed, though, going back twice to the same history item will result in the same itemSequenceNumber.  That will make FrameLoader think we've hit Stop instead of Back, so it will still corrupt the backForward history.

A better fix will let us uniquely match the ResourceRequest to the HistoryItem.  I'm uploading a draft of one way to do that, adding a unique ID to ResourceRequest and assigning it to the HistoryItem while the request is in progress.  I'm open to suggestions on how to improve it, though.

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