Opened 5 years ago

Closed 20 months ago

#226 closed defect (worksforme)

Blocked Flash ad leaves blank placeholder in Chrome

Reported by: arthur Assignee:
Priority: P3 Milestone:
Module: Platform Keywords: externaldependency
Cc: smultron45@…, manvel@…, sebastian, trev Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by arthur)

Environment

  • Chrome 33.0.1750.154 m
  • Windows 8.1 Pro x64
  • Latest ABP release or dev build
  • EasyList Germany+EasyList

How to reproduce

  1. Go to http://www.click-learn.de/

Observed behaviour

Blocked Flash ad on the right leaves a blank placeholder.

Expected behaviour

There should not be a placeholder.

Forum topic

https://adblockplus.org/forum/viewtopic.php?f=11&t=13600

Change History (14)

comment:1 Changed 5 years ago by arthur

  • Description modified (diff)

comment:2 Changed 5 years ago by mapx

  • Cc smultron45@… added

comment:3 Changed 5 years ago by arthur

  • Priority changed from Unknown to P3

comment:4 Changed 5 years ago by philll

  • Ready set

comment:5 Changed 5 years ago by saroyanm

  • Cc manvel@… added
  • Platform set to Unknown

comment:6 Changed 5 years ago by philll

  • Platform changed from Unknown to Chrome

comment:7 Changed 5 years ago by sebastian

  • Cc sebastian added
  • Component changed from Unknown to Platform

I could reproduce this issue. It seems that element collapsing doesn't work for some reason here. However it seems to be unrelated to #581.

comment:8 Changed 5 years ago by greiner

The issue is that the <object> element doesn't dispatch any event that we could listen to for detecting when it finished loading which we use to trigger the check that determines whether or not the element should be collapsed.

comment:9 follow-up: Changed 5 years ago by sebastian

Instead of listening to the error or load events, we could send a message form the background page to the content script when blocking a request.

Beside fixing this issue, it would also be more efficient since we won't have to match all request twice.

comment:10 Changed 5 years ago by sebastian

  • Cc trev added
  • Ready unset

Removing ready for now, until we decided if and how to fix that.

@trev, @greiner: What do you think about the approach I suggested?

comment:11 in reply to: ↑ 9 Changed 4 years ago by sebastian

Replying to sebastian:

Instead of listening to the error or load events, we could send a message form the background page to the content script when blocking a request.

I just realized a flaw with the approach I suggested earlier. It doesn't seem to be possible to map webRequest calls to elements in a reasonable way. In order to do so, we would have to walk through the entire tree, figuring out all URLs associated with each element, normalizing those URLs if necessary and comparing them to the blocked URL. That would be rather inefficient, requires a fairly complex solution, and might lead to false results in corner cases.

comment:12 Changed 4 years ago by sebastian

  • Keywords externaldependency added

I filed http://crbug.com/445557, to dispatch error/load events for <object> elements.

comment:13 Changed 20 months ago by sebastian

  • Tester set to Unknown

In May, a patch landed in Chromium, addressing this bug. I just tried to reproduce the issue in Chrome 61. However, it seems there is no Flash on https://www.click-learn.de anymore. So I went to http://www.tizag.com/flashTutorial/flashhtmlcode.php, and hid the Flash elements there (using the "Block element" dialog). No placeholders seem to appear (even after reloading).

Arthur, can you confirm that placeholders for blocked Flash elements, no longer appear in the latest version of Chrome? If so, feel free to close this issue.

comment:14 Changed 20 months ago by arthur

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

Yeah, looks like it.

Note: See TracTickets for help on using tickets.