Opened on 08/05/2016 at 12:57:25 AM

Closed on 08/15/2016 at 05:50:12 PM

Last modified on 08/15/2016 at 05:50:46 PM

#4305 closed defect (duplicate)

Popup isn't blocked if opened through local page with refresh in header.

Reported by: Lain_13 Assignee: sebastian
Priority: P3 Milestone:
Module: Platform Keywords:
Cc: kzar, sebastian, mapx, trev Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):



Windows 10
Google Chrome 52.0.2743.82 m
Adblock Plus development build

How to reproduce

  1. Open
  2. Remove cookies if any and refresh a page.
  3. Click on anything. Preferably on empty space.

Observed behaviour

A local page popup is opened and then immediately changes to an ad.

Example of a popup page code:
<META http-equiv="refresh" content="0;URL=">

Expected behaviour

Popup is closed after the redirect. Blocking popup itself is not an option since they avoiding blocks and also periodically using pop-downs (background redirects).

BTW, works fine in Firefox.

Attachments (0)

Change History (14)

comment:1 Changed on 08/05/2016 at 04:04:53 PM by mapx

  • Cc kzar sebastian mapx added

comment:2 Changed on 08/05/2016 at 05:05:00 PM by kzar

  • Component changed from Unknown to Platform
  • Priority changed from Unknown to P2
  • Ready set

Can reproduce, investigating...

comment:3 Changed on 08/05/2016 at 05:05:29 PM by kzar

  • Owner set to kzar

comment:4 Changed on 08/08/2016 at 10:43:13 AM by kzar

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

(Sorry, just realised this is a duplicate of #2095.)

comment:5 Changed on 08/08/2016 at 01:47:14 PM by Lain_13

This is not a duplicate of #2095 since redirect happens in a newly created tab. The occasionally use background redirect from another ads network, but this is not the case here.

Also, it's platform-specific issue. This popup is properly closed in Firefox while #2095 happens everywhere and not handled at all.

Last edited on 08/08/2016 at 01:52:24 PM by Lain_13

comment:6 Changed on 08/11/2016 at 12:01:52 PM by Lain_13

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Forgot I can reopen it myself.

As I stated above this issue is completely different from issue #2095:

  1. Between Fx and Ch it only happens in Chrome. #2095 happens everywhere.
  2. This issue based on a META http-equiv="refresh" tag in the header, while the other one is completely script-driven.
  3. This one happens in a newly opened tab (original site remains intact in the background tab), while the other one happens in the old tab while original site is opened in a new tab.

So, this issue is not a duplicate of #2095 no matter how you look at it.

BTW, this trick is also implemented on

Last edited on 08/11/2016 at 12:03:28 PM by Lain_13

comment:7 Changed on 08/13/2016 at 11:08:41 AM by kzar

  • Owner kzar deleted
  • Priority changed from P2 to Unknown
  • Ready unset

Well in that case perhaps I just misunderstood. What do you think Sebastian, duplicate of #2095 or not?

comment:8 Changed on 08/13/2016 at 12:53:06 PM by sebastian

While it is technically a background redirect happening inside the popup, I see how one would expect Chrome and Firefox to behave consistently at least, regardless of #2095.

Adblock Plus for Firefox keeps track of popups until they are closed, and matches any URL the popup navigates to again, closing the popup if the new URL is supposed to be blocked.

Adblock Plus for Chrome only keeps track of popups until they finished loading. So while we still consider any URL encountered while loading the popup (e.g. HTTP redirects), we ignore navigation that happens after the popup initially finished loading. This has been the behavior on Chrome ever since we implemented popup blocking there. There is even addional code that explicitly ensures this behavior.

However, while removing that code (i.e. the webNavigation.onCompleted handler in the current implementation) would make Chrome consistent with Firefox in the scenario here, it would worsen the impact of #3249. So that all links you click on pages that have been opened in a new tab would be considered popups, potentially causing the tab to be closed.

comment:9 Changed on 08/13/2016 at 06:21:01 PM by Lain_13

Looks like it's more complex than I thought. However, to me they still look like two similar, yet different issues. ABP never handled background redirects even in Firefox since it never tracked state of a tab the user just left while it already tracks state of a newly opened tab, yet, as you told, it does so only until it finishes loading.

Also, I don't think #3249 is really important - we had problems with way too generic filters since the beginning. So, if ://ads.$popup and similar filters cause more problems than they resolve (or just way too many) then they have to go, like /banners/* and many other similar filters did. It's always possible to add the code which will display an overlay panel with information about the blocked popup and propose to either open it or never display it on this site or at all. Or just keep a list of recently blocked popups in the ABP icon menu with ability to whitelist them if the user want and display something on the icon if popup got blocked.

So, even if they will share most of the code there still will be differences in details. For example ABP will have to track state of all backgound tabs to be able to close them while to "resolve" this one existing feature can be disabled.

comment:10 Changed on 08/14/2016 at 01:00:57 AM by Lain_13

Regarding #3249 - I've proposed there to wrap As I understood windows opened via this function is not marked as a popup anywhere by the browser and that is the reason why ABP can't distinguish between manually opened windows and windows opened from script. With #3249 solved it should be safe to remove onCompleted handler and solve this issue in the result.

Also, it should be possible to reuse this wrapper later on in #2095 to track source if target page is from the same domain.

Last edited on 08/14/2016 at 01:07:41 AM by Lain_13

comment:11 Changed on 08/15/2016 at 12:29:15 PM by sebastian

  • Priority changed from Unknown to P3
  • Ready set

Actually, not only pages opened with but also pages opened with links like <a href="..." target="_blank"> are to be considered popups. However, in both cases window.opener will be set in the popup. So we could actually detect whether it is a popup in the content script, messaging back to the background page. Then we can removed the webNavigation.onCompleted handler and forget navigation targets that have no window.opener instead. This would solve this issue as well as #3249.

comment:12 Changed on 08/15/2016 at 04:29:33 PM by sebastian

  • Owner set to sebastian

I have a working proof-of-concept which would solve this issue, however, if we want to address #3249 as well, I realized, we would have to defer closing the tab until our content script runs and confirms that there is a window.opener, hence making the popup more noticeable before it gets closed.

comment:13 Changed on 08/15/2016 at 05:50:12 PM by trev

  • Resolution set to duplicate
  • Status changed from reopened to closed

In fact, the way Firefox behaves right now is wrong. I filed #4335 on that, this bug was introduced in Adblock Plus 2.7.2 if I'm not mistaken. So the issue which was filed here is indeed a duplicate of #2095 - since the initial load already occurred here, it's no longer a pop-up. In order to prevent subsequent navigation #2095 is required.

comment:14 Changed on 08/15/2016 at 05:50:46 PM by trev

  • Cc trev added

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 sebastian.
Note: See TracTickets for help on using tickets.