"Block element" tool fails to suggest some blockable elements

[rscott]

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

• Browse to ​https://www.cnet.com/roadshow/news/fords-exoskeleton-could-help-factory-workers-in-a-big-way/
• Click the Adblock Plus icon
• Click "Block element"
• Mouseover the elements of the page.

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.

[kzar]

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.

[kzar]

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.

[Mcgregor123]

spam

[sebastian]

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