[Webkit-unassigned] [Bug 24949] Back out some of the changes to FrameLoader in r42055 to unbreak Chrome.

[bugzilla-daemon at webkit.org]

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


fishd at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com




------- Comment #3 from fishd at chromium.org  2009-03-30 16:47 PDT -------
Hi Darin,

We are using these FrameLoader methods from our WebKit layer, which we have not
yet upstreamed.  We are knee deep in cleaning up that layer so that we can
upstream it.

We use loadURL for browser driven navigations, and we use closeURL as part of
our asynchronous procedure for shutting down a WebView.  (WebView closure is
rather complicated in Chrome for good reasons, which I can explain if you
like.)

We need setCurrentHistoryItem and setProvisionalHistoryItem to support the way
we have implement back/forward.  You see, we don't keep the back/forward list
in the same process as WebKit.  You might recall the BackForwardListClient
interface from me that you reviewed several months back.  That (as well as
these FrameLoader methods) enable us to maintain the back/forward list
separately.  So, to navigate back or forward, we instead navigate to a
particular HistoryItem.  Getting that to work properly requires a bit of work.

While we work to upstream all of the Chromium WebKit layer, I hope that you
will be supportive of re-exposing these methods on FrameLoader.  I think it
would be a lot easier to refactor our code once it lives in svn.webkit.org.  Of
course, if there are any obvious alternatives to these methods, I would love to
hear about them.

Can we at least land Jeremy's change as a bustage fix?


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