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

[Lain_13]

Environment

Windows 10
Google Chrome 52.0.2743.82 m
Adblock Plus development build 1.12.1.1628

How to reproduce

1. Open ​http://rustorka.com/forum/index.php
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=http://utarget.ru/ranging/18a7c76811/click/">

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.

[kzar]

Can reproduce, investigating...

[kzar]

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

[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.

[Lain_13]

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 ​http://rumedia.ws/

[kzar]

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

[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.

[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.

[Lain_13]

Regarding #3249 - I've proposed there to wrap window.open. 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.

[sebastian]

Actually, not only pages opened with windows.open() 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.

[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.

[trev]

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.