Opened on 08/28/2014 at 10:48:50 AM
Closed on 03/03/2015 at 07:53:05 PM
#1282 closed defect (fixed)
"Block element" creates filter for whitelisted elements
Reported by: | passbrains | Assignee: | sebastian |
---|---|---|---|
Priority: | P3 | Milestone: | Adblock-Plus-1.8.12-for-Chrome-Opera-Safari |
Module: | Platform | Keywords: | |
Cc: | sergz, sebastian, mapx, philll, greiner, kzar, trev | Blocked By: | #1853 |
Blocking: | Platform: | Chrome | |
Ready: | yes | Confidential: | no |
Tester: | Verified working: | no | |
Review URL(s): |
Description (last modified by sebastian)
Adapted from https://www.passbrains.com/dashboard/view-ticket.php?ticket_no=AOP-18
Environment
Chrome/Opera/Safari
How to reproduce
- Go to https://en.wikipedia.org/wiki/Portable_Network_Graphics
- Click the ABP icon and choose "Block Element"
- Click on the example image in the right column
- Save the filter
- Reload the page
Observed behaviour
A request blocking filter for following URL is added:
https://upload.wikimedia.org/wikipedia/commons/thumb/9/9a/PNG_transparency_demonstration_2.png/280px-PNG_transparency_demonstration_2.png
However the image isn't blocked because following exception rule in EasyList:
@@||upload.wikimedia.org/wikipedia/
That is because exception rules always override blocking rules.
Expected behaviour
No filter which won't have any effect because an exception rule should be suggested.
Attachments (1)
Change History (19)
Changed on 08/28/2014 at 10:48:53 AM by passbrains
comment:1 Changed on 08/28/2014 at 11:42:32 AM by sebastian
- Cc sebastian added
- Component changed from Unknown to Platform
- Description modified (diff)
- Platform changed from Opera to Chrome
- Priority changed from Unknown to P3
- Ready set
- Summary changed from Block element feature is not fully functional for .PNG elements. to "Block element" creates filter for whitelisted elements
comment:3 Changed on 08/28/2014 at 01:02:21 PM by mapx
- Cc mapx added
comment:4 follow-up: ↓ 6 Changed on 09/26/2014 at 09:26:17 AM by sebastian
- Cc philll greiner kzar trev added
- Ready unset
comment:5 Changed on 12/04/2014 at 03:24:07 PM by sergz
- Cc sergz added
comment:6 in reply to: ↑ 4 Changed on 12/04/2014 at 03:26:30 PM by greiner
Replying to sebastian:
So far it seems that the majority is in the favor to let user defined filters override whitelisting filters.
Yes, that would be the best user experience IMHO. However, not sure yet how well this can be integrated with the existing filter matching mechanism since we currently don't take a filter's origin (i.e. in which filterlist(s) it was defined) into consideration.
comment:7 follow-up: ↓ 8 Changed on 12/04/2014 at 04:10:44 PM by sebastian
Letting the user override exception rules from filter lists would certainly be nice. But doesn't seem to be trivial to implement, and might also impair the performance.
Alternatively, we could extend the filter validation (#491) to prevent users from adding filters that are overridden by exception rules. The downside with that approach is that exception rules added to filter lists can still conflict with existing custom filters without noticing. But this case can probably be neglected.
For reference, this issue has been reported 5 times within the past 2 weeks via passbrains.
comment:8 in reply to: ↑ 7 Changed on 12/08/2014 at 06:28:30 PM by greiner
Replying to sebastian:
Alternatively, we could extend the filter validation (#491) to prevent users from adding filters that are overridden by exception rules.
This would only work for element hiding filters since the exception rule for a hiding filter is basically the same filter with just minor differences. For blocking filters, however, we require a context to determine which filters match and since a user can freely edit the filters we cannot rely on the context the suggested filters were initially based on.
Therefore I'd suggest not to suggest filters in the first place which we know would have no effect because of an existing exception rule.
comment:9 Changed on 12/09/2014 at 07:33:10 AM by sebastian
Sure, the "Block element" dialog shouldn't suggest any filters which won't have any affect, as described in the issue description. But I guess we should address it in the filter validation as well, otherwise we will have the same issue when users add custom filters.
comment:10 Changed on 12/09/2014 at 10:22:30 AM by philll
If we are really serious about letting the user have control, we should imo rather go through a complex process of implementing the feature to have overwrites.
comment:11 Changed on 12/09/2014 at 11:17:33 AM by sebastian
I just hacked together a proof of concept. Apparently it was easier than expected, and also simpler than the alternatives, to make user-defined filters override filter lists. However, I'd like to know what trev thinks about that patch. Whether this change is reasonable, given that additional code has to run for every filter match, and might have an effect on the performance.
comment:12 Changed on 12/09/2014 at 10:05:04 PM by trev
Mind you, the solution for Firefox was a much more pragmatic one: you cannot create filters for whitelisted elements. And you aren't really solving the reported issue here because the next issue will say "Block element creates filter for user-whitelisted elements". I'm not saying that we shouldn't let user-defined filters have higher priority, it's merely an entirely different issue - not even the same component.
comment:13 Changed on 12/13/2014 at 02:28:13 PM by sebastian
- Description modified (diff)
- Ready set
- Review URL(s) modified (diff)
- Status changed from new to reviewing
You are right, letting users override filter lists with custom filters, is in fact a separate issue. And letting the user do so, won't fix this issue in scenarios where a user-defined exception rule is whitelisting the element. So lets just not generate filters conflicting with exception rules.
comment:14 Changed on 12/13/2014 at 02:28:27 PM by sebastian
- Owner set to sebastian
comment:15 Changed on 12/15/2014 at 02:31:31 PM by sebastian
- Description modified (diff)
comment:16 Changed on 01/22/2015 at 03:12:53 PM by sebastian
- Blocked By 1853 added
comment:17 Changed on 02/12/2015 at 04:19:00 PM by greiner
comment:18 Changed on 03/03/2015 at 07:53:05 PM by sebastian
- Milestone set to Adblock-Plus-for-Chrome-Opera-Safari-next
- Resolution set to fixed
- Status changed from reviewing to closed
Removing ready for now, since we don't seem to agree, how to address this issue.
So far it seems that the majority is in the favor to let user defined filters override whitelisting filters.