[Webkit-unassigned] [Bug 37126] REGRESSION (r56223): http://www.playerpress.com/ shows up twice in the back/forward list.

[bugzilla-daemon at webkit.org]

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





--- Comment #16 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-04-07 11:32:52 PST ---
(In reply to comment #15)
> (In reply to comment #14)
> > Please ignore comment #13.  I was wrong.  It is not changing the reference
> > fragment.  It is navigating from about:blank.
> > ...
> > I think a possible fix for us, and perhaps what Firefox is doing, is to keep
> > history locked when navigating from about:blank.
> 
> I think that sounds pretty reasonable.
> 
> If it works, we should consider getting that specifically into HTML5 (if it's
> not already there in some roundabout way that we both missed)

I think the solution may need to be a bit more subtle, which is why I haven't
posted a patch yet.  What I think we really need to know is 1) are we
navigating away from about:blank and 2) has the iframe been navigated anywhere
else?

That is, if the iframe is newly constructed and has only loaded about:blank,
then I think the next navigation should have lockHistory/lockBackForwardHistory
set to true.

I am actually struggling a bit to see how best to implement that condition in
WebCore.  FrameLoader has a committedFirstRealDocumentLoad() method that looks
like it should be applicable here, but sadly that is set to true as a byproduct
of FrameLoader::requestFrame("about:blank").  That may actually be a bug in
itself.  Or, perhaps we should have a requestFrameWithEmptyDocument method to
make things more clear.

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