Opened on 04/08/2019 at 07:35:57 PM
Closed on 08/14/2019 at 04:58:18 PM
Last modified on 08/15/2019 at 02:52:42 AM
#7451 closed change (duplicate)
Add support for running snippets on specific platforms
Reported by: | mjethani | Assignee: | |
---|---|---|---|
Priority: | Unknown | Milestone: | |
Module: | Core | Keywords: | circumvention |
Cc: | hfiguiere, amrmak | Blocked By: | |
Blocking: | #6538, #6812 | Platform: | Unknown / Cross platform |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Background
(This is just an idea at this point.)
It has come up that filter list authors might want to deploy a snippet on one or more domains only on a specific platform. This could be done by extending the syntax of snippet filters to allow for meta arguments, like so:
example.com#$#[platform=gecko] hide-elements .ad-label
Meta arguments may even solve the problem of versioning of snippets, by letting filter list authors deploy a snippet only on a specific version or range of versions of Adblock Plus.
This could also be done using named arguments (#6812):
example.com#$#hide-elements selector=.ad-label platform=gecko
In this case, the snippet would check the value of the platform argument and decide not to run any code based on the value. Not every snippet may want to do this check, so it could be done by a wrapper similar to the function returned by makeInjector() in lib/content/snippets.js. Since named arguments would also solve other problems, this might be the more practical approach, at least for now.
What to change
[TBD]
Attachments (0)
Change History (6)
comment:1 Changed on 04/09/2019 at 05:53:07 PM by hfiguiere
comment:2 Changed on 04/10/2019 at 11:18:10 AM by mjethani
From what I could tell, the actual problem was only with snippets, and this is understandable given that snippets are experimental compared to core features (we often find out that a snippet is not working on a particular platform after the test build).
As for how to apply this to any filter, I think that would require more fundamental changes. If we want simply to use the syntax of existing kinds of filters, then we can do this for request blocking filters ($platform=) and snippet filters (the proposal here), but clearly there's no way to do this for element hiding filters unless we extend the syntax and complicate things further. On the other hand, I can't think of a good reason why one would want this for element hiding filters.
Nevertheless, the short term approach to solve relatively current problems is to do this for snippet filters only.
comment:3 Changed on 08/14/2019 at 12:41:46 PM by amrmak
- Cc amrmak added
comment:4 Changed on 08/14/2019 at 04:14:16 PM by hfiguiere
I have moved this bug to:
https://gitlab.com/eyeo/adblockplus/adblockpluscore/issues/60
comment:5 Changed on 08/14/2019 at 04:58:18 PM by hfiguiere
- Resolution set to duplicate
- Status changed from new to closed
comment:6 Changed on 08/15/2019 at 02:52:42 AM by hfiguiere
- Sensitive unset
I think the intent was actually for *any* type of filter. Given that some content provider server different content based on the browser, it make sense to be able to do that in extreme cases.