Opened on 11/05/2016 at 09:36:45 AM

Closed on 11/28/2016 at 04:45:28 PM

Last modified on 03/13/2017 at 03:39:41 PM

#4603 closed defect (fixed)

Block element tool highlighting is broken by certain element hiding filters

Reported by: xqwztis Assignee: kzar
Priority: P3 Milestone: Adblock-Plus-1.13-for-Chrome-Opera
Module: Platform Keywords:
Cc: kzar, sebastian, mapx, Lain_13 Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

Description (last modified by kzar)


Chrome 54, Adblock Plus 1.12.4

No filter subscriptions at all, only this filter:


How to reproduce

  1. Browse to (or any other website)
  2. Click the Adblock Plus icon and then "Block element".
  3. Roll the cursor over the page to select an element to block.

Observed behaviour

No elements are highlighted as the mouse passes over them.

Expected behaviour

Blockable elements should be highlighted yellow.

Attachments (0)

Change History (15)

comment:1 Changed on 11/05/2016 at 09:52:59 AM by xqwztis


Extensions: 13

Apps: 5

Last edited on 11/05/2016 at 09:54:07 AM by xqwztis

comment:2 Changed on 11/05/2016 at 10:25:01 AM by mapx

  • Cc kzar sebastian mapx added

comment:3 Changed on 11/19/2016 at 03:26:48 PM by mapx

well, all this strange behaviour is due to this filter in ruadlist:


whitelisting it all is ok.

The question is: how could a hiding filter provoke such weird behaviour ?

Last edited on 11/19/2016 at 03:27:48 PM by mapx

comment:4 Changed on 11/19/2016 at 03:51:05 PM by mapx

  • Cc Lain_13 added

comment:5 Changed on 11/19/2016 at 03:51:20 PM by mapx

comment:6 Changed on 11/19/2016 at 05:33:22 PM by dimisa

comment:7 Changed on 11/28/2016 at 12:30:14 PM by kzar

  • Component changed from Unknown to Platform
  • Description modified (diff)
  • Priority changed from Unknown to P3
  • Ready set
  • Summary changed from Adblock Plus doesn't highlight elements to be blocked (mac OS Sierra) to Block element tool highlighting is broken by certain element hiding filters

Can also reproduce this on Linux so seems unrelated to operating system.

comment:8 Changed on 11/28/2016 at 12:56:50 PM by kzar

  • Owner set to kzar

comment:9 Changed on 11/28/2016 at 01:47:12 PM by kzar

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

The filter composer highlights elements by creating an overlay on top of them which is translucent yellow / red. The troublesome filter was simply hiding those elements!

Turns out our code had a typo, it was giving the overlay elements the style of display: inline-box instead of display: inline-block, but I also needed to add !important in order to fix this problem.

(What made this a little trickier to debug was that a code comment was out of date and the code was a little confusing. (We used to sometimes highlight elements by adding styles to them, instead of always using overlays. But that is no longer the case.) I added another review to at least improve the comments.)

comment:10 Changed on 11/28/2016 at 04:44:33 PM by abpbot

comment:11 Changed on 11/28/2016 at 04:45:28 PM by kzar

  • Milestone set to Adblock-Plus-for-Chrome-Opera-next
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:12 Changed on 11/28/2016 at 09:46:28 PM by mapx

well, the solution is unfortunately based on the inability of ABP for chrome to hide the elements with style's !important keyword.

if I use Lain's userscript (in tampermonkey) "it's not important" the issue is still not fixed.

This userscript is used exactly to fight the increasingly large number of sites using the !important trick.

comment:13 Changed on 11/29/2016 at 01:45:45 AM by Lain_13

I'd actually recommend to give an element a random string as an ID and operate it through a STYLE element. This way it will have only an ID and will never be hidden by complex style-based filters.
Please, don't use static prefixes or suffixes since some sites attempt to exploit it in order to break user's ability to hide ads on their page in an easy way.

comment:14 Changed on 11/29/2016 at 11:05:36 AM by kzar

Well I considered using the random ID / class approach, but that would add quite a bit of complexity for almost no gain. The case of element hiding filters matching our overlays is already rare enough, the combination of that with the use of Lain's userscript is even rarer.

At some point in the future it would be nice to tidy up some of the block element code further, perhaps then we could improve this too, but in the mean time I think the !important workaround is good enough, sorry.

Last edited on 11/29/2016 at 11:06:12 AM by kzar

comment:15 Changed on 03/13/2017 at 03:39:41 PM by Ross

  • Tester changed from Unknown to Ross
  • Verified working set

Fixed. Element hiding is improved compared to 1.12.4.

Chrome 49 / 56 / Windows 10
Chrome 56 / OS X 10.12
Chrome 56 / Ubuntu 16.04
Opera 37 / 41 / Windows 7
Safari 10 / OS X 10.12

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 kzar.
Note: See TracTickets for help on using tickets.