WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
UNCONFIRMED
120195
Expose the reason for a ResourceRequest to bindings
https://bugs.webkit.org/show_bug.cgi?id=120195
Summary
Expose the reason for a ResourceRequest to bindings
Ben Boeckel
Reported
2013-08-22 20:08:05 PDT
In
Bug #117678
, I'm requesting that GTK expose the reason for a request so that AdBlockPlus can be fully implemented[1]. After digging, I see that this information is not available. [1]
https://adblockplus.org/en/filters#options
Attachments
Add-a-reason-field-to-ResourceRequest
(5.18 KB, patch)
2014-03-05 00:35 PST
,
Ben Boeckel
andersca
: review-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ben Boeckel
Comment 1
2014-03-05 00:35:26 PST
Created
attachment 225866
[details]
Add-a-reason-field-to-ResourceRequest Initial patch attached. I'm not sure which 'reasons' could/should be merged together (or split). This doesn't change any call sites or method signatures (another patch goes through the repo and adds reason parameters and updates callers).
Anders Carlsson
Comment 2
2014-03-05 07:18:48 PST
Comment on
attachment 225866
[details]
Add-a-reason-field-to-ResourceRequest This looks like a layering violation to me. A ResourceRequest shouldn't know about what it's for. Can't this be put on the ResourceLoader level? There's also no rationale for why this is needed at all.
Ben Boeckel
Comment 3
2014-03-05 08:07:23 PST
Feature rationale: I work on uzbl[1] and I'd like to implement support for AdBlockPlus filter rules[2] for adblocking. The problem is that the rules specify that, e.g., they only apply for images, JS, or CSS files which WebKit doesn't offer at all. I'd also like to put some auditing in to drive the Lightbeam[3] code in uzbl. Location: ResourceRequest seemed like the best place since the ResourceLoader would otherwise need to get the information through some other path in places and notification of the reason would likely come through changed notification APIs (e.g., willSendRequest would need a reason parameter added to it). In WebKit2, the reason would need to get back to the UIProcess somehow and it seemed to fit there as well. I can try to take a stab at moving it into the loader(s) itself. [1]
http://uzbl.org
[2]
https://adblockplus.org/en/filters#options
[3]
https://en.wikipedia.org/wiki/Lightbeam_%28software%29
Ben Boeckel
Comment 4
2014-03-05 13:11:42 PST
Another rationale for going into ResourceRequest is that the referrer is there, which is arguably another "reason" the request is being made.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug