Opened on 05/23/2018 at 03:07:53 PM

Closed on 05/30/2018 at 10:48:17 AM

Last modified on 06/13/2018 at 10:34:47 AM

#6692 closed defect (fixed)

$document doesn't whitelist everything inside iframes

Reported by: arthur Assignee: kzar
Priority: P1 Milestone: Adblock-Plus-3.2-for-Chrome-Opera-Firefox
Module: Platform Keywords:
Cc: scuturic, kzar, sebastian, Ross Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

Description (last modified by kzar)


  • Windows 10 Pro
  • Chrome 66.0.3359.181 (Official Build) (64-bit)
  • ABP
  • EasyList Germany+EasyList
  • Acceptable Ads

How to reproduce

  1. Enable ABP to run in incognito mode (chrome://extensions/?id=ldcecbkkoecffmfljeihcmifjjdoepkn)
  2. Open an incognito window
  3. Go to or
  4. Open like products below "LAUTSPRECHER UND MEHR IM ANGEBOT" and wait until finished loading (this is necessary to target ads for you)
  5. Go to
  6. Open the dev tools panel, click on the "Adblock Plus" tab and refresh the page
  7. Choose "whitelisted" in the top left drop-down item so you would only see the whitelisted resources
  8. Note the whitelisted iframes are whitelisted by @@||$subdocument,document in Acceptable Ads
  9. Switch from "whitelisted" to "blocked" in the top left drop-down
  10. Note or more resources (like from are blocked coming from the document domain

Observed behaviour

Requests within the iframe are being blocked, no ads appearing above the fold on the right side (next and under the newsletter box).

Expected behaviour

Every request within the iframe should load since it is whitelisted by $subdocument,document. Ads should appear above the fold on the right side (next and under the newsletter box).


  • Keep in mind the ads might stop appearing even when everything works. In that case close the incognito window and start targeting again.
  • This is a regression caused by this commit 1cf57a70f44b.

Hints for testers

  • Verify you can no longer reproduce the symptoms described above.
  • Verify that you can still no reproduce the problem described in #6595.
  • On both Firefox and Chrome do a bunch of testing, checking things like the block counter, blocking, whitelisting and $sitekey whitelisting still work.

Attachments (0)

Change History (16)

comment:1 Changed on 05/23/2018 at 03:09:38 PM by arthur

  • Description modified (diff)

comment:2 Changed on 05/24/2018 at 04:25:55 PM by sebastian

  • Milestone set to Adblock-Plus-for-Chrome-Opera-Firefox-next
  • Priority changed from Unknown to P1
  • Ready set

Reproduced. Since this appears to be a new regression, we should look into it before the next release.

comment:3 Changed on 05/24/2018 at 05:21:42 PM by kzar

I could reproduce this for a while (the blocked requests, but I never saw the advert) and was attempting to bisect. Unfortunately I can no longer see those requests no matter how many times I try to reproduce the setup again, I guess they logged my IP or something.

I'm pretty sure I saw the request get blocked for 3.1 too, so I'm not convinced this is a regression since the last release. I'll attempt again to reproduce tomorrow, hopefully they'll have forgotten my IP by then.

comment:4 Changed on 05/25/2018 at 03:43:30 PM by arthur

Instead of you might want to try

comment:5 Changed on 05/29/2018 at 02:19:00 PM by kzar

  • Description modified (diff)

comment:6 Changed on 05/29/2018 at 03:52:54 PM by kzar

  • Description modified (diff)

Thanks, I could reproduce it more reliably this time with I've managed to bisect and find the problematic commit.

Unfortunately the commit in question was attempting to work around limitations with the Chrome extension APIs we use to keep track of pages and frames, changes to this code tends to fix 2 things and break something else! Such problems are often non-trivial and involve race conditions which will only show up on certain websites or at certain times.

comment:7 Changed on 05/29/2018 at 04:30:34 PM by kzar

  • Owner set to kzar

One option might be to restore the old onBeforeNavigate listener whilst keeping the new onCommitted listener. That way we'd update the page frame structure earlier in this case, whilst still catching the Service Worker case (#6595) which the previous change fixed. Hardly ideal to duplicate this work, but then none of this is.

comment:8 Changed on 05/29/2018 at 04:36:18 PM by sebastian

Did you confirm that this workaround would work (which would mean that the issue here is that the frame structure is updated for the about:blank frames not before they sent any requests otherwise)?

comment:9 Changed on 05/29/2018 at 04:49:01 PM by kzar

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

comment:10 Changed on 05/29/2018 at 04:50:45 PM by kzar

Yes, seems to work OK. I tested that this issue no longer happens and that #6595 still doesn't. But I'm open to suggestions if you can think of a better approach, I'm hardly happy to do it this way.

comment:11 Changed on 05/29/2018 at 04:58:42 PM by sebastian

I don't have any beter idea either, besides a minor simplification, I suggested on the code review.

comment:12 Changed on 05/30/2018 at 10:39:18 AM by abpbot

A commit referencing this issue has landed:
Issue 6692 - Update frame structure for about:blank frames earlier

comment:13 Changed on 05/30/2018 at 10:48:17 AM by kzar

  • Cc Ross added
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:14 follow-up: Changed on 06/12/2018 at 01:05:39 PM by Ross

In Chrome: This seems to be fixed in that adverts now show on the right as described. However some requests (such as the are still listed as blocked in the Adblock Plus devtools panel). Should that still be blocked?

In Firefox: The adverts do not load at all. The frame and the Anzeige title are present, but it looks like requests from the frame are blocked.

Firefox 60 / Windows 8
Chrome 66 / Windows 8

comment:15 in reply to: ↑ 14 Changed on 06/13/2018 at 08:33:13 AM by arthur

Replying to Ross:

However some requests (such as the are still listed as blocked in the Adblock Plus devtools panel). Should that still be blocked?

I think that is correct since it is being loaded from the publisher's site.

This looks fixed to me. It is also working in Firefox for me (60.0.2, Win 10).

comment:16 Changed on 06/13/2018 at 10:34:47 AM by Ross

  • Tester changed from Unknown to Ross
  • Verified working set

Thank you for checking! Since it works for you in Firefox and I can see it's fixed in Chrome I'll mark this verified.

Firefox 60 / Windows 10
Chrome 66 / 49 / Windows 8
Opera 36 / 52 / Windows 8

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.