Opened on 06/03/2015 at 05:04:20 PM

Closed on 06/08/2015 at 10:26:57 AM

#2632 closed defect (invalid)

Block element behaviour on <area> elements seems incorrect

Reported by: passbrains Assignee:
Priority: Unknown Milestone:
Module: Unknown Keywords:
Cc: sebastian, Ross Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Verified working: no
Review URL(s):

Description (last modified by Ross)

Adapted from


Windows + 8 64bit + Chrome + English
ABP version

How to reproduce

  1. Install latest ABP extension on Chrome Browser
  2. Load page
  3. Click on ABP icon and click on 'Block element'. Select top element in the right corner as shown in screen shot.
  4. Add the filter.

This is <area> element. But issue #1868 does not exist. <area> element mentioned in issue #1868 is blocked.

Observed behaviour

Element is not blocked.

Expected behaviour

Element is blocked.

Attachments (1)

3766_1432393494_chromeBlock.png (774.1 KB) - added by passbrains on 06/03/2015 at 05:04:26 PM.

Download all attachments as: .zip

Change History (6)

Changed on 06/03/2015 at 05:04:26 PM by passbrains

comment:1 Changed on 06/03/2015 at 05:04:29 PM by passbrains

1 - 03 Jun 2015 17:04:11 posted by Ross Green

Selecting the position in the screenshot:

  1. Suggests the first gif in a child of the #navSwmHoliday which is actually just a 1x1 image.
  1. Confirming that filter then blocks that image (which doesn't "hide" that promotion as it is displayed with a different background-image deeper in the tree).
  1. Attempting to Block element on that promotion now just doesn't work. No dialog appears at all which as a user is confusing.

Chrome 43.0.2357.81 / Windows 8.1 x64

comment:2 Changed on 06/03/2015 at 05:21:40 PM by Ross

  • Description modified (diff)
  • Summary changed from Element is not blocked. to Block element behaviour on <area> elements seems incorrect

I confirmed this one because the behaviour seems to be/feels incorrect.

It only suggests one image, the first image, which is not necessarily the correct one. If it isn't the correct image, blocking it causes the user to not be able to select that set of elements again for some reason.

So from a user POV, they attempted to block something, it didn't do anything and now they can't try again without manually removing that filter (which if they have a lot of, will be difficult to find).

I'm not 100% sure it's related to <area> tags, but the same user reported #2115 which involves the same set of elements.

comment:3 Changed on 06/07/2015 at 04:55:53 PM by sebastian

  • Cc sebastian Ross added

When you select that <area> element the corresponding image is correctly blocked. However, this image is just transparent. So there is no visible effect. But once that transparent image has been removed, you could select the element it was covering, wouldn't element hiding being disabled on by Acceptable Ads.

Though it might be confusing in this particular case, everything seems to work as intended. That element simply can't be blocked as long as you using Acceptable Ads. Therefore it can't be selected by the "Block element" feature.

comment:4 Changed on 06/08/2015 at 07:01:11 AM by Ross

Ah, I didn't know element hiding was disabled on Acceptable Ads. I agree everything seems to be working as intended in that case (also agree that it's confusing, especially that the user gets no feedback as to why it doesn't work).

comment:5 Changed on 06/08/2015 at 10:26:57 AM by sebastian

  • Resolution set to invalid
  • Status changed from new to closed

Note that before #1282 you could select elements that were whitelisted. However, this was even more confusing, as the added filters won't have any effect.

But in the particular case here, it is confusing because you can block the transparent image, but not the element below. However, this is rather a corner case.

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.