[Webkit-unassigned] [Bug 80713] Add new methods to FrameLoaderClient so different WebKit ports can customize the ResourceRequest when it is created.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 13 11:31:02 PDT 2012


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





--- Comment #45 from jochen at chromium.org  2012-03-13 11:31:01 PST ---
(In reply to comment #44)
> (In reply to comment #43)
> > It's not clear to me how the ResourceRequest created by XMLHttpRequest will be annotated with the XHR target type using your proposed set of callbacks.
> 
> Yeah that is a problem. Do you think it make sense to call frame()->loader()->client()->customizeSubresourceRequest() in XMLHttpRequest::createRequest()?

That's not possible, as the XHR might be created on the worker thread, so we have to jump to the main thread first before we can invoke methods on the FrameLoaderClient

> 
> > In comment #35 you said that in order to plumb the target type everywhere, we'd need to cache it in ResourceLoadScheduler. I was referring to that comment: I don't think that's a big issue, as we do that already e.g. in CachedResource.cpp (i.e. the information what target type to use is kept in the cache so we can attach it to the resource request when we need it)
> 
> So you mean it is fine for us to leave these #ifdef there? And add more when it is needed?

No, I want to get rid of the ifdefs

target type should not be part of resource request

Instead, all loader related methods that take a resource request should also take a target type parameter, e.g. ThreadableLoader::create should take ScriptExecutionContext, ThreadableLoaderClient, ResourceRequest, TargetType, and ThreadableLoaderOptions parameters.

TargetType could either be owned by FrameLoader or some other class in loader/

> 
> I actually don't mind this approach that much, just thought removing these platform #ifdef and doing all these customization in BlackBerry platform will be cleaner.

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



More information about the webkit-unassigned mailing list