Opened on 03/18/2018 at 09:24:12 PM

Closed on 08/29/2019 at 05:43:18 PM

#6495 closed change (rejected)

Filter composer should allow more control over which elements are hidden/blocked

Reported by: mapx Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords: closed-in-favor-of-gitlab
Cc: kzar, sebastian, mjethani, hfiguiere, greiner, agiammarchi, athornburgh, jeen Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)

Environment

Windows 10, Chrome 66, Adblock Plus dev build 3.0.2.1983

How to reproduce

  1. Navigate to http://axistrivia.altervista.org/_test1.html
  2. Click the ABP icon, select "block element"
  3. Select the third element on the page (select the entire row - otherwise a blocking filter will be suggested)

Observed behaviour

A hiding filter is suggested, which hides all the elements on the page: axistrivia.altervista.org##.column

Expected behaviour

A more specific hiding filter could be suggested, e.g. axistrivia.altervista.org##.column:nth-of-type(3).

Alternatively the "Block element" tool could provide a way to make the suggested filter more or less specific.

Attachments (1)

create filters uBo.png (12.4 KB) - added by mapx on 03/19/2018 at 07:06:56 PM.

Download all attachments as: .zip

Change History (12)

comment:1 Changed on 03/18/2018 at 09:25:47 PM by mapx

  • Cc greiner agiammarchi added

comment:2 Changed on 03/18/2018 at 10:46:39 PM by mapx

  • Description modified (diff)
  • Summary changed from ABP should propose more specific hiding filters to ABP should suggest more specific hiding filters

comment:3 follow-up: Changed on 03/19/2018 at 03:13:21 PM by kzar

  • Cc athornburgh jeen added
  • Component changed from Platform to User-Interface

I think this is another example of why the "block element" tool needs to provide a way for the user to make the suggested filter more or less specific. I'm not exactly how the UI should look here, in some situations the user might want to select the parent / child element but in other situations (like this one) things get more complicated.

comment:4 in reply to: ↑ 3 Changed on 03/19/2018 at 03:25:41 PM by greiner

Replying to kzar:

I think this is another example of why the "block element" tool needs to provide a way for the user to make the suggested filter more or less specific. I'm not exactly how the UI should look here, in some situations the user might want to select the parent / child element but in other situations (like this one) things get more complicated.

I agree that we need to be careful not to make filters we suggest too specific as long as there's no easy way for users to modify them.

On the other hand, removing parts of a filter is easier than adding new parts so it may be sufficient for now to make sure that we highlight all matching elements whenever the filters change.
I think spec#140 may provide a good foundation for that since it mentions "Live preview of changes - give feedback in real time when the suggested filter is edited by the user so they know which element would be hidden/blocked."

Changed on 03/19/2018 at 07:06:56 PM by mapx

comment:5 Changed on 03/19/2018 at 07:07:25 PM by mapx

see the attached image what is suggesting uBo:

  • first pic ==> when the image is selected a blocking filter and cosmetic (hiding) filters are suggested
  • second pic ==> when the entire row (with the image) is selected ==> only a hiding filter is suggested

So, you could see how uBo is managing such feature

(sure, is suggesting the correct positional filter and the preview feature is doing its job)

Last edited on 03/19/2018 at 07:08:44 PM by mapx

comment:6 Changed on 10/10/2018 at 12:43:22 PM by greiner

  • Component changed from User-Interface to Platform

Moving this ticket to Platform because that's where the logic for suggesting filters is located.

comment:7 Changed on 10/16/2018 at 11:08:58 AM by kzar

  • Cc sebastian added
  • Description modified (diff)
  • Summary changed from ABP should suggest more specific hiding filters to Filter composer should allow more control over which elements are hidden/blocked
  • Type changed from defect to change

comment:8 Changed on 10/16/2018 at 12:34:36 PM by greiner

Regarding the suggested UI changes to more precisely select an element on the page, I've created #7049 so that we can focus on the filter suggestion changes in this ticket.

comment:9 Changed on 10/16/2018 at 01:23:39 PM by kzar

But I think the two are closely related, hiding elements by a class might be desirable on one page but not another. The only way we can make this work IMO is to provide a UI which allows the user to block/hide more or less.

comment:10 Changed on 10/16/2018 at 02:38:32 PM by greiner

I agree that they're closely related. At least my impression was that suggesting filters through the element picker and correcting filters through the filter composer were separate tasks.

So you don't think there's a way we can either make more accurate predictions on what filters the user expects or make improvements to the element picker to achieve that? Because if that's the case we may indeed need to fall back to the filter composer for correcting suggested filters.

comment:11 Changed on 08/29/2019 at 05:43:18 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.