Opened 5 years ago

Closed 5 years ago

#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 5 years ago.

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by passbrains

comment:1 Changed 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago 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.

Note: See TracTickets for help on using tickets.