Opened on 11/03/2016 at 04:00:43 PM

Closed on 02/28/2017 at 12:50:06 PM

Last modified on 03/13/2017 at 08:32:45 AM

#4599 closed defect (fixed)

Third party filters blocking first party requests

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

Description (last modified by kzar)


Win 8.1
Chrome 54.0.2840.87
Adblock Plus 1.12.4 with only the filter ||^$third-party and no subscriptions.

How to reproduce

  1. Create a new Chrome tab
  2. Type the URL into the URL bar.
  3. Hit the Enter key.


  1. Browse to
  2. Click on the link.

Observed behaviour

The page layout is often broken since the page's stylesheet was blocked. It doesn't happen every time but it does quite often. If you then refresh the page the stylesheet will not be blocked.

Expected behaviour

The page should be displayed correctly, the stylesheet shouldn't be blocked.


Attachments (0)

Change History (31)

comment:1 Changed on 11/03/2016 at 04:03:30 PM by arthur

  • Cc sebastian kzar added

comment:2 Changed on 11/03/2016 at 07:41:17 PM by mapx

  • Cc mapx added

comment:3 Changed on 11/06/2016 at 09:42:18 AM by mapx

  • Cc trev added

comment:4 Changed on 11/06/2016 at 09:46:48 AM by mapx

it seems a lot of sites have the same wrong behaviour:

How to reproduce it:

open a new tab, type

  • the css file will be blocked
  • F5 refresh ==> the page works fine

If you whitelist the site, repeat the steps above ==> the css file blocked again !

Could be a regression while fixing:
1649: 2016-08-31 17:11 +0200 Wladimir Palant
Issue #4386 - Fixed determining document domain, particularly after being redirected

see also in forum:

If you add

the issue is gone.

There is only a third-party filter in easylist:

Last edited on 11/06/2016 at 09:52:08 AM by mapx

comment:5 Changed on 11/06/2016 at 10:04:53 AM by mapx

  • Summary changed from CSS blocked on in Chrome to CSS blocked on all sites in easylist with ||^$third-party filters

comment:6 Changed on 11/06/2016 at 10:09:28 AM by mapx

  • Cc offir added

comment:7 Changed on 11/06/2016 at 10:32:57 AM by mapx

  • Summary changed from CSS blocked on all sites in easylist with ||^$third-party filters to CSS blocked on all sites in easylist with $third-party filters

comment:8 Changed on 11/09/2016 at 11:44:31 AM by trev

I'd rather expect #4483 to be the cause.

comment:9 Changed on 11/09/2016 at 11:48:12 AM by kzar

  • Owner set to kzar

comment:10 Changed on 11/09/2016 at 02:36:15 PM by kzar

  • Description modified (diff)
  • Priority changed from Unknown to P1
  • Ready set
  • Summary changed from CSS blocked on all sites in easylist with $third-party filters to Third party filters blocking first party requests for pre-rendered pages

I can reproduce this too with Chrome 54 on Linux. I agree it's likely to be a regression, going to try and track down what caused this now.

comment:11 Changed on 11/09/2016 at 03:12:02 PM by kzar

  • Description modified (diff)

Like Wladimir I expected the recent changes for #4483 to be to blame but it seems Mapx was right and that the changes for #4386 caused this. I can reproduce the problem with the Issue 4386 - Fixed determining document domain, particularly after being redirected revision but not before.

comment:12 Changed on 11/09/2016 at 03:19:24 PM by mapx

yep, I was guessing is 4386 because the symptoms are the same as in the original 4386
"If you whitelist the site, repeat the steps above ==> the css file blocked again"

comment:13 Changed on 11/09/2016 at 03:30:45 PM by kzar

  • Description modified (diff)

comment:14 Changed on 11/10/2016 at 09:47:19 AM by kzar

Edit: I was mistaken, since as Sebastian pointed out in the code review Chrome gives pre-rendered pages a new tab id. As for the $sitekey stuff, I've opened #4632 for that.

Unless I'm mistaken it's basically the same problem as #4483.

If a page makes a web request before its onCommitted event has fired the request will be blocked / whitelisted based upon the old page structure. So if the URL for the previous page was of a different domain the request will be considered third party, or if the new page has a sitekey we won't know to take it into account.

Thing is the old behaviour was no better, arguably worse. The onBeforeNavigate event we used wasn't fired after redirections, so the page structure was not updated at all for those. Also it was fired for pre-rendered pages which meant that we effectively assumed that pre-rendered pages would always be navigated to. So we can't simply revert #4386 and I think it's a little unfair to consider this issue a regression caused by that change.

Ultimately I think we need to rethink the page structure logic so that pre-rendered pages can be accounted for properly. While we're at it I think adding unit tests for how the page structure is maintained based upon navigation events would be a pretty good idea. I don't think this is the right time to do that however since in the near future we plan to remove some of the Page abstractions (e.g. #4580) and other ext code now that Safari support has been dropped. I think it would make more sense to wait until after that work has been done.

So what can we do for now? Well how about we update the page structure both on onBeforeNavigate and onCommitted. We could remove the workaround for #4483 while at it and look at maintaining the page structure properly after the ext code has been removed. This would mostly be correct and not require major changes.

(Updating the page structure for pre-rendered pages is incorrect but perhaps that doesn't matter too much. One pre-rendered page will replace another until the user eventually has finished typing the URL. The latest guess should always be handled correctly. The only problem would be if the user stopped typing the URL and then continued to use the existing page without navigating at all. Note this was the case before #4483 landed so apparently not too much of a problem.)

Last edited on 11/12/2016 at 08:38:14 AM by kzar

comment:15 Changed on 11/10/2016 at 02:44:33 PM by kzar

(Dang, looks like I was at least partially mistaken since the $sitekey whitelisting for requests directly after a redirect broke when I took the #4483 workaround out. I'll see if the approach otherwise works now.)

Last edited on 11/12/2016 at 08:39:02 AM by kzar

comment:16 Changed on 11/10/2016 at 03:19:30 PM by kzar

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

comment:17 Changed on 11/11/2016 at 08:17:04 PM by esanchez

  • Cc esanchez added

comment:18 Changed on 11/15/2016 at 12:22:00 PM by kzar

  • Description modified (diff)
  • Summary changed from Third party filters blocking first party requests for pre-rendered pages to Third party filters blocking first party requests

(Turns out this is not only for pre-rendered pages.)

comment:19 Changed on 11/16/2016 at 12:43:27 PM by kzar

(I filed Chromium issue 665843 for the underlying problem that pages and frames can make requests before their onCommitted event has fired.)

comment:20 Changed on 11/16/2016 at 06:32:43 PM by kzar

  • Review URL(s) modified (diff)

comment:21 Changed on 11/17/2016 at 04:05:55 PM by kzar

  • Cc added

comment:22 Changed on 11/17/2016 at 05:05:50 PM by arthur

  • Cc arthur added

comment:24 Changed on 12/12/2016 at 05:42:40 PM by mapx

comment:25 Changed on 01/07/2017 at 10:35:27 AM by sebastian

  • Milestone set to Adblock-Plus-for-Chrome-Opera-next

comment:26 Changed on 01/12/2017 at 12:34:01 PM by arthur

Is this the same issue?

Copy this URL, paste it into the address bar and press enter. Some resources are being blocked while they shouldn't. It's fine if you reload the page.

comment:27 Changed on 01/16/2017 at 10:41:29 AM by kzar

Yes, that sounds like the same issue.

comment:28 Changed on 02/10/2017 at 10:18:11 AM by 8ball

I have this issue on ABP for CHROME and OPERA - upon first load of my websites homepage my adsense advert is being blocked even when disabled on the site, if i refresh the page it displays...all other ads on website display fine.. just the homepage one doesnt

comment:29 Changed on 02/28/2017 at 12:50:06 PM by kzar

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:30 Changed on 02/28/2017 at 12:51:20 PM by kzar

A commit referencing this issue has landed:
Issue 4598,4599,4647,4804 - Work around onCommitted flaw

comment:31 Changed on 03/13/2017 at 08:30:30 AM by Ross

  • Tester changed from Unknown to Ross
  • Verified working set


Chrome 49 / 56 / Windows 10
Chrome 56 / OS X 10.12
Chrome 56 / Ubuntu 16.04
Opera 37 / 41 / Windows 7
Safari 10 / OS X 10.12

Last edited on 03/13/2017 at 08:32:45 AM by Ross

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.