Bug 39112 - FrameLoader: refactor loadFrameRequest() not to use FrameLoadRequest
Summary: FrameLoader: refactor loadFrameRequest() not to use FrameLoadRequest
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Chris Jerdonek
URL:
Keywords:
Depends on:
Blocks: 39111
  Show dependency treegraph
 
Reported: 2010-05-14 04:36 PDT by Chris Jerdonek
Modified: 2011-06-14 09:47 PDT (History)
4 users (show)

See Also:


Attachments
Proposed patch (12.90 KB, patch)
2010-05-14 21:23 PDT, Chris Jerdonek
no flags Details | Formatted Diff | Diff
Proposed patch 2 (16.47 KB, patch)
2010-05-14 21:29 PDT, Chris Jerdonek
cjerdonek: review-
cjerdonek: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Jerdonek 2010-05-14 04:36:50 PDT
Refactor FrameLoader::loadFrameRequest() to take a ResourceRequest and String frame name instead of a FrameLoadRequest.  This will make the signature of loadFrameRequest() more similar to the signatures used predominantly by the other load methods.  This should aid future refactoring of the FrameLoader class by making opportunities for code sharing more evident.  This is also a step towards eliminating the FrameLoadRequest class (bug 39111).
Comment 1 Chris Jerdonek 2010-05-14 21:23:21 PDT
Created attachment 56137 [details]
Proposed patch
Comment 2 Chris Jerdonek 2010-05-14 21:29:25 PDT
Created attachment 56138 [details]
Proposed patch 2

I forgot to re-diff before attaching patch 1.
Comment 3 Adam Barth 2010-05-16 06:48:42 PDT
Comment on attachment 56138 [details]
Proposed patch 2

Hum...  It seems strange that "loadFrameRequest" wouldn't load a FrameLoadRequest.

I think we probably want to go in the other direction: make a bigger "request" object that we can pass around that includes things like lock history, etc.  Is there some reason you think breaking this down into a smaller object is better?
Comment 4 Chris Jerdonek 2010-05-16 11:27:14 PDT
(In reply to comment #3)
> (From update of attachment 56138 [details])
> Hum...  It seems strange that "loadFrameRequest" wouldn't load a FrameLoadRequest.

Yes, I noticed this, though wouldn't the correct name be loadFrameLoadRequest()?

> I think we probably want to go in the other direction: make a bigger "request" object that we can pass around that includes things like lock history, etc.

It's funny you mention this.  When I had studied the history of FrameLoadRequest, the last change was to remove lock history:

http://trac.webkit.org/changeset/40373/trunk/WebCore/page/FrameLoadRequest.h

> Is there some reason you think breaking this down into a smaller object is better?

For now, yes.  I think there is a good chance we may eventually want some abstraction like this, but I don't know if it's the right one.  In the short-term, given that the 4-year life of FrameLoadRequest hasn't really bought us anything here, I thought it would be better to make the various load methods look more similar.  This will make it somewhat easier to see opportunities for code sharing across the various load methods, etc.  If we prematurely clump things, it may be harder to do this.

After this change, FrameLoader::createWindow() will be the only place in FrameLoader.h using FrameLoadRequest.  And that function is getting moved out of the FrameLoader class in bug 39156.

Given all that, the dependency doesn't seem needed.
Comment 5 Chris Jerdonek 2010-05-21 10:21:02 PDT
Comment on attachment 56138 [details]
Proposed patch 2

Marking r- to remove from pending review while considering Adam's comments.