[Webkit-unassigned] [Bug 49113] New: [chromium] Add a way for the embedder to tag a ResourceRequest with arbitrary data

[bugzilla-daemon at webkit.org]

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

           Summary: [chromium] Add a way for the embedder to tag a
                    ResourceRequest with arbitrary data
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fishd at chromium.org
                CC: levin at chromium.org, pierre.lafayette at gmail.com


[chromium] Add a way for the embedder to tag a ResourceRequest with arbitrary data

The problem is that we are teaching WebKit to store fields on ResourceRequest that
are meaningless to WebKit.  We are doing that just so we can pass information from
WebFrameClient::willSendRequest to WebURLLoader.  m_requestorID, m_requestorProcessID,
and now m_hasUserGesture (see bug 37057) are in this category.

I suspect we may be better served by generalizing this.  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.

We also need to worry about CrossThreadResourceRequestData, which is
used to copy the contents of a ResourceRequest across threads.  Or,
perhaps we can say that the ExtraData here would not be shared across
threads.  (I don't think we need it to be copied in Chromium, but that
might change in the future.)

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