Blocking different kind of pop-ups

[Deathamns]

Here is the test case I used for Firefox.
Chrome only blocks the first three types.

[gorhill]

I could host the server-side code on my server. Very useful, instead of going around to try to find some test cases.

[Deathamns]

1. Allow CORS for XHR.
2. t.php: <?php header('Location: t1.php');
3. t1.php: <?php header('Location: http://example.com/AdHandler.aspx?');

Save the HTML, change the URLs which are pointing to the php files, upload.

[gorhill]

http://raymondhill.net/ublock/popup.html

[Deathamns]

data:uri link redirect should have a full URL, and the XHR URL too.

[gorhill]

Fixed now?

[Deathamns]

:63 http://raymondhill.net/ublock/popup-t.php instead of popup-t.php
:72 http://raymondhill.net/ublock/AdHandler.aspx? instead of ?AdHandler.aspx?
(since the baseURI is not inherited...)

[gorhill]

Yes, that's what I fixed. Oh wait.. 72 is wrong.... Fixed

[Deathamns]

Have you uploaded it too? Because I still don't see the full URLs.

[gorhill]

Now I did, I was uploading at the wrong location..

[Deathamns]

Seems okay, except 11. Chrome should display "not ok" (for now). Maybe upload an empty AdHandler.aspx too.

[Deathamns]

A few of the examples above could be easily supported in Chrome, by allowing about:blank and data: type URIs for the main frame. So, basically allow a pagestore to be created for these URLs.
In Firefox, I just faked http URLs for them, but that is not a solution.

Because of this, I simply ignored vAPI.tabs.onNavigation for non-http pages (because in that step the pagestore is destroyed, meaning no ads will be blocked in the pop-up), which is now causing #522.

[gorhill]

allowing about:blank and data: type URIs for the main frame

Yes, I will go the uMatrix route: allow uBlock on these, as I want uBlock to now catch everything since it can disclose all connections. This will also take care of issue #105.

[gorhill]

@Deathamns:

A few of the examples above could be easily supported in Chrome, by allowing about:blank and data: type URIs for the main frame. So, basically allow a pagestore to be created for these URLs.
In Firefox, I just faked http URLs for them, but that is not a solution.

This is fixed in branch https://github.com/gorhill/uBlock/tree/fix-475. However I am not sure if Firefox code needs more changes than what I did. Also, is there such a thing as "behind-the-scene" in Firefox?

If so, they should be reported with the tab id set to vAPI.noTabId.

[Deathamns]

if Firefox code needs more changes

Probably frameModule.js needs to be changed.

If so, they should be reported with the tab id set to vAPI.noTabId.

It returns -1 (just like others) for requests that are not related to tabs :370.

[Deathamns]

URL; pop-up (via clicking) not blocked.
No problem in similar extensions (Chrome too).

[gorhill]

Isn't just a filter thing? If I use ||racksauce.com^ (or block dynamically) no popup.

Edit: I see a regular expression filter in EasyList for promptfile.com:

/^https?\:\/\/(?!(connect\.facebook\.net|www\.google-analytics\.com|ajax\.googleapis\.com|netdna\.bootstrapcdn\.com|[\w\-]+\.addthis\.com|bp\.yahooapis\.com|b\.scorecardresearch\.com|platform\.twitter\.com)\/)/$script,third-party,xmlhttprequest,domain=promptfile.com

I don't want uBlock to support regex if there are other ways to do the same thing. Which is the case here: only ||racksauce.com^ is needed along with the default selection of lists instead of that large regular expression.

[Deathamns]

I didn't check. It didn't seem right, so I made a note for later testing.
But, yes, it seems that it is blocked in ABP because of a regular expression type filter.

[ryanbr]

regex was only supported because the domains were changing so often, it was easier to block via regex. Does uBlock actually support any regex? example: https://hg.adblockplus.org/easylist/rev/c50fec88ffc8

[gorhill]

@RyanR: this does the job as far as I can tell:

|http://$popup,domain=filenuke.com|sharesix.com
||filenuke.com/a/script.js$script
||sharesix.com/a/script.js$script

Edit: corrected after d/l'ing latest EasyList

[ryanbr]

Our regex for filenuke and sharesix stops the randomly generated scripts from running. Also its easier for filenuke/sharesix to change /a/script.js continuously. Personally I'd prefer to attempt to break popup scripts.

[gorhill]

@ryanbr

Personally I'd prefer to attempt to break popup scripts

Agreed. Looking at it closer, it does look to me the following filter would match the same as the new regexes which were added:

||nvy.sharesix.com/*/*$script

[ryanbr]

The subdomain kept changing, if you see some of the commits for filenuke; https://hg.adblockplus.org/easylist/log?rev=filenuke.com you'll see what I mean

[gorhill]

It's an eternal cat and mouse game, they are obviously keeping an eye on EasyList, and will just craft the name of their scripts to go around whatever filter is current -- even if it's a regex. Now it's their turn to counter.