Loading…
Exception filter `@@||yoursite.com^$document` doesn't seem to work #5
3 participants
Gee I have no clue what the option document means (reading the official doc didn't help). Anyone?
The spreadsheet "Filter options" on the ABP cheatsheet says:
Used to whitelist the page itself (e.g. @@||example.com^$document)
And this forum thread which discusses full domain blocking also suggests that this option is used for full domain whitelisting.
Used to whitelist the page itself
But that's the default behavior, ABP never blocks main doc requests. And as for whitelisting whole domain, @@||example.com^ would work just fine, isn't?
I suppose this means I can just discard the now meaningless document option (I guess it was useful back when ABP could block main doc requests).
Perhaps this explanation helps.
@@||example.com^$document - allow everything (from any domain) while surfing on example.com
@@||example.com^$~document - allow everything hosted on example.com (no matter whether you're currently on example.com or not)
@@||example.com^ - both of the above
In other words: @@||example.com^ is more comprehensive than @@||example.com^$document
Thanks, I see now.
I used it to disable adblock on specific pages, like @@||youtube.com/^$document => only disables adblock on the homepage, not on the search / view pages.
By the way, https://github.com/gorhill/uBlock/wiki/Change-log#0109 release date :)
By the way, https://github.com/gorhill/uBlock/wiki/Change-log#0109 release date :)
I don't have a zip for this one. I had one, which was mainly for submission to the Opera store, then there was an issue which now I forgot and I had to cancel the submission, and by the time I re-submitted I was at 0.1.0.10. I forgot what was the issue with 0.1.0.9, looking at the details in commits would probably refresh my memory.
Edit: Ok, there was that in 0.1.0.9: gorhill/uBlock@a6496e5. I thought because of it it was not worth having a version for 0.1.0.9, it's a bad bug.
This is, by the way, used to whitelist sites (not whole domains), for example I don't care about ads on the Youtube start page (so path = '/'), but I don't like the in-video ads.
Do you have any plans to work on this? If not I'd love to take look at it.
@gorhill
Although it would be nice to have the $document option, it works more as a whitelist. So, instead of implementing the document option, you (I) could extend the current whitelist, to support pages (http://domain.tld/sub/folder/whitelisted) or whole hostnames (as it's now) as input.
I don't mind supporting it as a filter. But frankly the meaning still confuses me. Forget the exception form, I want to understand the basic form:
||example.com^$document
What does this accomplish, and how is this different than:
||example.com^
I still don't get it.
"document — the page itself (only exception rules can be applied to the page)" from the official doc :)
Everything on example.com is allowed only while you're surfing on example.com
If you meant that for ||example.com^$document the definition is "Everything on example.com is blocked only while you're surfing on example.com", than I think I get it.
What needs to be tested when the $document option is present is the URL of the page, not the URL of the request. The result is then saved internally and from there this means all the embedded content of the page is blacklisted (the block form), or all the embedded content of the page is whitelisted (the allow form), completely disregarding filtering for embedded content.
Amirite?
Sorry, I had not seen that the @@ were missing ;-)
However, https://adblockplus.org/en/filters#options clearly says:
"document — the page itself (only exception rules can be applied to the page)"
In other words, this option does not apply to blocking rules.
In other words, this option does not apply to blocking rules
Well, I will support it internally, and the user if free to create such a rule if he chooses to. I don't see why this would be forbidden if someone wants it as their own filter.
Well, I will support it internally, and the user if free to create such a rule if he chooses to. I don't see why this would be forbidden if someone wants it as their own filter.
Supporting this would not cause any harm, I suppose. On the other hand, is it really useful? This option would - as discussed above - block a whole site only while surfing on it. But if you block a site (usually a malware domain/adserver/tracker) you would definitely prefer
||example.com^
as it is simply more comprehensive (it blocks anything from that site even if you're not surfing on it). I don't really see any cases where using this option would be useful (but perhaps my imagination is not vivid enough ;-) ). And that's probably the reason why it was abandoned for blocking rules (siteblocking) in ABP.
Again, if it doesn't hurt - why not? But I think it's of little avail, if any.
On the other hand, is it really useful?
It's useful code-wise: I don't have to create an exception for that particular filter. No exception means no special code path. No special code path means simpler logic and less code. Simpler logic and less code means lower likelihood of bugs and unwanted side effects.
I understand. This makes sense.
Ok, this will have to wait. It's not that simple. I actually see only one such filter in EasyList (out of the 47,000+ lines):
@@||oascentral.feedroom.com/realmedia/ads/adstream_sx.ads/brighthouse.com/$document,domain=oascentral.feedroom.com
There are six more, but they come with the subdocument keyword, which if I understand properly means, "disable filtering for when the request is made from within the frame". Actually I am not even sure how to read aloud such filter:
@@||accounts.google.com^$document,subdocument,domain=adwords.google.com
Given the probable infrastructure work required, given the (very low) occurrences of such a filter option, and given the low demand for such a filter option, it certainly doesn't look like a priority compared to other issues on the lists. I'm sending this back to the boiler plate for now.
I understand that, but at the moment there is no other possibility to whitelist a single page (e.g. only gorhill/uBlock#5, not whole github). With this filter syntax it is possible. On the other hand, I'd say it'd be better to just upgrade the current whitelist, to support subpages, not only hostnames.
I understand that, but
If you look at all the issues opened for uBlock and HTTPSB, which ones in your opinion need to be addressed first for when I dedicate time to write some code? Would this one here be on that list of issues which are to be fixed first for the benefit of a majority of users?
Of course not, but a whitelist is still a huge part of an Adblocker, that's what I wanted to point out. No hurries, take your time!
Just stopped by to write that I used this form of filter ONCE to completely disable filtering for one page, while blocking lots of resources from the others.
As it's not implemented for now, i switched to more precise resource blocking for now, and it wasn't without a bit of pain for me.
For me, a simple page whitelist would suffice.
I will implement ability to whitelist a specific web page.
Thank you!
This is need some testing before an official release, due to numerous changes throughout: https://github.com/gorhill/uBlock/releases/tag/0.3.2.0-rc0
I just tried the rc on a couple of sites, and whitelisting works very well. Holding the Ctrl key while clicking the power switch to get a URL-based whitelist directive is really cool and seems to work reliably.
Regarding the tooltips: They are not readable because they are (nearly completely) hidden behind the popup menu.
There is no custom tooltip, these are the default as per browser: I really just added title attributes on the elements. What browser/version are you using?
Google Chrome v. 36 64 bit on Arch Linux
Problem has to be the browser, as said, I just created title attributes, the browser decides how to render these. Try Disconnect, it has similar tooltips.
You're right. Same problem with Disconnect.
What window manager are you using on Arch?
KWin. I'm a KDE fanboy.
From the feedback section in the chrome store.