[Webkit-unassigned] [Bug 37057] [chromium] Adding hasUserGesture flag to the ResourceRequest

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 5 14:17:32 PDT 2010


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





--- Comment #21 from Pierre-Antoine LaFayette <pierre.lafayette at gmail.com>  2010-11-05 14:17:32 PST ---
(In reply to comment #20)
> (From update of attachment 72992 [details])
> This patch looks good, but I'm now questioning whether we should do it like
> this.  The problem is that we are teaching WebKit to store fields that are
> meaningless to it.  We are doing that just so we can pass information from
> WebFrameClient::willSendRequest to WebURLLoader.  hasUserGesture is not the
> first example of this, so I feel bad making this your problem, but we have
> to clean up the code at some point.  m_requestorID and m_requestorProcessID
> similarly exist only to support the embedder, Chromium.
> 
> Instead, I suspect we may be better served by jumping to the solution I
> mentioned in comment #11.  We already do something like that for WebDataSource.
> See WebDataSource::ExtraData.  One difference is that the ExtraData that would
> be associated with a ResourceRequest needs to be copied when a ResourceRequest
> is copied.  The DocumentLoader (which WebDataSource wraps) does not get copied
> in the same way, so it does not have this problem.
> 
> Something like reference counting seems like the right answer...
> 
> class WebURLRequest {
> public:
>     class ExtraData {
>     public:
>         virtual void ref() = 0;
>         virtual void deref() = 0;
>     protected:
>         ~ExtraData() { }
>     };
> 
>     WEBKIT_API ExtraData* extraData() const;
>     WEBKIT_API void setExtraData(ExtraData*);
>     ...
> };
> 
> Unfortunately, though, we do not permit referring to WebKit:: classes
> from WebCore, so we wouldn't want to directly stash one of these
> WebURLRequest::ExtraData pointers on ResourceRequest.  We'd need to
> either create another interface like ExtraData at the ResourceRequest
> level, or we'd need to find some way to stash the pointer in some
> opaque fashion :-(  I don't have a good answer for this.
> 
> Given the current patch, even though you don't need it, perhaps you
> should consider amending CrossThreadResourceRequestData.

This refactoring would be a separate issue. Are you saying that it needs to be done before this patch or after?

-- 
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