Bug 25118 – Add signal to support AdBlock in WebKit

• Status: RESOLVED
• Resolution: INVALID
• Component: Page Loading

[Alejandro G. Castro]

We want to add support to block resources inside the webpages based on their URL, that way the browsers could block parts of the web based on a URL.

The idea is to have a delegate in the DocLoader::requestResource (WebCore/loader/DocLoader.cpp), something like:

...
    KURL fullURL = m_doc->completeURL(url);

    if (!fullURL.isValid() || !canRequest(type, fullURL) || (badURL == fullURL))
        return 0;

For webkit version of epiphany this signal will allow us to keep the ad block support that is implemented with the current version based on gecko.

[Alejandro G. Castro]

Sorry last comment was not finished:

The idea is to have a delegate in the DocLoader::requestResource (WebCore/loader/DocLoader.cpp), something like:

...
    KURL fullURL = m_doc->completeURL(url);

    if (!fullURL.isValid() || !canRequest(type, fullURL) || (blockResource(type, fullURL)))
        return 0;
...

Maybe we could even add it in the canRequest function as a last line if the other conditions are satisfied.

This function will delegate in the browser to check if the the resource should be loaded or not.

Is this support already implemented? Is this the proper place?

[Alejandro G. Castro]

Created attachment 29389 [details]
Rough example patch of the proposal

This is a initial and rough patch better than the pseudocode in the comment to explain how it could be done. It adds the Gtk delegate implementation. We have not added the type of the resource to the parameters of the dispatch function just to simplify. I've tested to handle the signal in Epiphany browser and at least it does the work, I've set TRUE to the return value and no resource is loaded.

[Mark Rowe (bdash)]

I think WebCore already supports this functionality by way of FrameLoaderClient::dispatchWillSendRequest.  If the client callback clears the request object then the load will be cancelled. The client also has the option of mutating the request (changing the URL, adding extra headers, or replacing it with a completely different request), which makes this much more flexible.  This willSendRequest client callback just needs to be hooked up in the GTK port to provide the functionality that you're after.

[Alejandro G. Castro]

Thanks for the information Mark, we will use that delegate.