Bug 54744 – Add Prerendering Motivation information to ResourceRequest

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Gavin Peters]

Add Prerendering Motivation information to ResourceRequest

[Gavin Peters]

Created attachment 82955 [details]
Patch

[Gavin Peters]

See http://codereview.chromium.org/6542016/ for the chromium code review that uses this feature.

[Adam Barth]

Comment on attachment 82955 [details]
Patch

I thought the client had a way to associate arbitrary information with a resource request without teaching WebCore what that information was.

[Adam Barth]

Looks like the arbitrary data thing hasn't happened yet:

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

This seems like a good use case for it.

[Eric Seidel (no email)]

Comment on attachment 82955 [details]
Patch

"triggeredByPrerendering" or "forPrerendering" seem better than "hasPrenderingMotivation" (which is quite a mouthful).

I agree with Adam, seems this would be better to store off in Chromium land instead of in WebCore if possible.

Unless WebCore really needs to know about it being a prerender?

[Eric Seidel (no email)]

(I'm sure one could come up with better, or more concise names than the two I suggested as well.)

[Gavin Peters]

Created attachment 82997 [details]
Patch

[Adam Barth]

Gavin has promised to fix Bug 49113 after landing this patch.

[Gavin Peters]

(In reply to comment #5)
> (From update of attachment 82955 [details])
> "triggeredByPrerendering" or "forPrerendering" seem better than "hasPrenderingMotivation" (which is quite a mouthful).

You are right.  I've uploaded a new patch.

> 
> I agree with Adam, seems this would be better to store off in Chromium land instead of in WebCore if possible.
> 
> Unless WebCore really needs to know about it being a prerender?

WebCore does not need to know about it being a prerender.

I think both you and Adam are right, and 49113 is the right way forward; requiring WebKit changes for load information to pass through each time Chrome gets more clever about request life is not a sustainable way forward.

Adam asked me to promise that I'd work on 49113 to make this ugliness go away: By these words I promise that I will hack at 49113.  This will come up in Chrome networking again as we improve prioritization of requests, since information about the origination of requests (a hidden tab?  a visible tab? ...) will motivate that.  As well I know other folks here who have similar FavIcon changes for Auth they want.  I'll try and talk them into waiting on 49113.

[Darin Fisher (:fishd, Google)]

Actually, now I'm not sure why this is needed.  Can't you derive the exact same information from the requestorID, which corresponds to the RenderView's routing ID (aka, the view ID)?

From the browser process, you can observe the routing ID associated with a network request, and you should be able to keep a set of routing IDs corresponding to pre-rendered pages browser-side.

[Gavin Peters]

Comment on attachment 82997 [details]
Patch

I'm removing review? and commit-queue? as we're thinking of other ways to move this information over on the chromium bug thread.

[Gavin Peters]

Comment on attachment 82997 [details]
Patch

Now totally obsolete; a chrome only solution to this has landed.