Opened on 03/28/2014 at 12:53:23 PM
Closed on 09/21/2017 at 08:14:32 AM
#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@gmail.com, manvel@adblockplus.org, 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
Observed behaviour
Blocked Flash ad on the right leaves a blank placeholder.
Expected behaviour
There should not be a placeholder.
Forum topic
Attachments (0)
Change History (14)
comment:2 Changed on 04/02/2014 at 08:18:11 AM by mapx
- Cc smultron45@gmail.com added
comment:3 Changed on 04/23/2014 at 08:11:27 PM by arthur
- Priority changed from Unknown to P3
comment:4 Changed on 04/30/2014 at 10:34:37 AM by philll
- Ready set
comment:5 Changed on 07/06/2014 at 02:10:59 PM by saroyanm
- Cc manvel@adblockplus.org added
- Platform set to Unknown
comment:6 Changed on 07/09/2014 at 12:54:54 PM by philll
- Platform changed from Unknown to Chrome
comment:7 Changed on 07/15/2014 at 08:44:03 PM by sebastian
- Cc sebastian added
- Component changed from Unknown to Platform
comment:8 Changed on 07/16/2014 at 02:16:03 PM 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: ↓ 11 Changed on 07/16/2014 at 07:40:17 PM 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 on 09/25/2014 at 01:32:58 PM 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 on 12/26/2014 at 04:53:59 PM 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 on 12/30/2014 at 12:04:00 PM by sebastian
- Keywords externaldependency added
I filed http://crbug.com/445557, to dispatch error/load events for <object> elements.
comment:13 Changed on 09/21/2017 at 05:10:12 AM 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 on 09/21/2017 at 08:14:32 AM by arthur
- Resolution set to worksforme
- Status changed from new to closed
Yeah, looks like it.
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.