Opened 11 months ago

Last modified 9 months ago

#6048 new defect

"Block element" tool fails to suggest some blockable elements

Reported by: rscott Assignee:
Priority: P2 Milestone:
Module: Platform Keywords:
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)

Environment

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 @@||cnet.com^$elemhide

Reproduction

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.

Notes

  • 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.

Change History (3)

comment:1 Changed 11 months ago by mapx

  • Cc kzar sebastian mapx mjethani added

comment:2 Changed 9 months ago 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 9 months ago 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.

Note: See TracTickets for help on using tickets.