Opened on 11/16/2017 at 06:54:41 PM

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

Last modified on 10/08/2019 at 06:03:36 PM

#6048 closed defect (rejected)

"Block element" tool fails to suggest some blockable elements

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

Description (last modified by kzar)


Linux Ubuntu 16.04 64-bit with both:

Chromium 62.0.3202.89/ABP Chrome 1.13.4
Firefox 56.0/ABP FF 3.0.1

No subscriptions, only the filter @@||^$elemhide


Observed behaviour

Almost nothing on the page can be highlighted with the yellow "Block element" overlay, only the google ad inside the iframe at the top of the page. Because of this, it's impossible to add a filter for such page elements via this method.

Expected behaviour

Whilst we've prevent element hiding with our whitelisting filter, blockable elements should be able to be highlighted, clicked, and filter rules added.


  • The mouseOver event fires for the parent of the blockable element sometimes, but we only traverse up through the tree looking for blockable elements.
  • For adverts inside iframes with no src we could possibly block the elements inside the iframe, but it's not obvious to the user that they'll need to use the context menu for that.
  • For elements which need element hiding rules nothing is suggested since we've whitelisted those. What can we do to make the situation more understandable / useful for our users? I've opened #6338 for a discussion about that.

Attachments (0)

Change History (5)

comment:1 Changed on 11/16/2017 at 07:35:34 PM by mapx

  • Cc kzar sebastian mapx mjethani added

comment:2 Changed on 01/29/2018 at 03:46:13 PM by kzar

  • Description modified (diff)
  • Owner set to kzar
  • Priority changed from Unknown to P2
  • Ready set

Well it's expected that we no longer suggest any element hiding filters, so the "block element" tool won't work for elements that we need to fall back to hiding for. However it seems you're right that we also are suggesting very few blocking filters, even for elements which should be blockable. I'm going to look into this now to see if there's something we can improve.

comment:3 Changed on 01/29/2018 at 06:00:21 PM by kzar

  • Cc hfiguiere greiner added
  • Description modified (diff)
  • Owner kzar deleted
  • Summary changed from Element hiding exception rules can hide "Block element" overlay to "Block element" tool fails to suggest some blockable elements

So getBlockableElementOrAncestor() in composer.postload.js is used to figure out if the current element is somehow blockable. It works by first seeing if the current mouseover element has a blockable src or similar attribute and if no then tries it's parent recursively. It seems that for some of these images the mouseOver event fires for a parent of the element we'd like to block, so for the tool to work it'd also have to somehow try children - however I'm not sure how that would work in practice.

Another aspect is that some of the ads are inside iframe elements with no src, their contents might be blockable by right-clicking on it and using the "Block Element" context menu, but that's not be obvious to our users.

Finally it might not be obvious to users that they are trying to block an element that has already been whitelisted, or what they can do about that. I've opened #6338 for a discussion, so that we can keep this issue focused on improving the blockable element selection code.

comment:4 Changed on 08/07/2019 at 06:47:41 AM by Mcgregor123


Last edited on 10/08/2019 at 06:03:36 PM by kzar

comment:5 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
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.