Opened 2 years ago

Last modified 5 weeks ago

#3249 new defect

Popup blocking is applied to pages opened by the user in a new tab

Reported by: mapx Assignee:
Priority: P3 Milestone:
Module: Unknown Keywords:
Cc: trev, greiner, sebastian, SMed79, kzar, mjethani, arthur Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by mapx)

Environment

chrome 47 ABP 1.9.3.1488
still happens in Chrome Version 62.0.3202.62 (Official Build) beta (64-bit) ABP 1.13.4.1892

How to reproduce

update easylist
go to
https://adblockplus.org/forum/viewtopic.php?p=141887#p141887

1.in chrome try to open any of the links there, for example:
https://ads.nipr.ac.jp/
try clicking the middle mouse button or even open link in a new tab
The attempts will fail due to the filter:

://ads.$popup

2.try the same in firefox ==> no issue, the new tab will be opened.

Expected behavior

Popup blocking filters should not cause tabs opened by the user to be closed.

Change History (20)

comment:1 Changed 2 years ago by trev

  • Cc sebastian added
  • Description modified (diff)

Added Analysis section to the description. From what I remember, checking window.opener wasn't possible in Chrome, maybe Sebastian can confirm.

comment:2 Changed 2 years ago by trev

In fact, neither chrome.webNavigation.onBeforeNavigate (sourceTabId) nor chrome.tabs (openerTabId) seem to distinguish between user-opened and website-opened tabs, the tab ID of the original tag is set regardless - much unlike window.opener.

comment:3 Changed 20 months ago by mapx

other test case
http://uptobox.com/w851onwc1ujq

Liste FR contains this filter:

|http://$popup,domain=uptobox.com

clicking the middle mouse button or even open link in a new tab (for example for home link/button) fails.

comment:4 Changed 20 months ago by mapx

  • Cc SMed79 added

comment:5 Changed 20 months ago by mapx

  • Cc kzar added

comment:6 Changed 20 months ago by sebastian

  • Component changed from Adblock-Plus-for-Firefox to Platform
  • Description modified (diff)
  • Owner set to sebastian
  • Priority changed from Unknown to P3
  • Ready set
  • Summary changed from Different behaviour firefox / chrome in treating the popups requests to Popup blocking is applied to pages opened by the user in a new tab

As trev indicated above, the webNavigation API doesn't distinguish between actual popups and pages opened in a tab by the user. However It seems to be possible to identify popups by their windowType.

Last edited 20 months ago by sebastian (previous) (diff)

comment:7 Changed 20 months ago by sebastian

  • Component changed from Platform to Unknown
  • Owner sebastian deleted
  • Ready unset

Apparently, I was too ambitious that the Chrome API does what it indicates. Even though "popup" is a documented value for windowType, it's not used for popups created with window.open() as those are presented as regular tabs. So yeah, unfortunately, I don't see any way either to distinguish between actual popups and pages opened in a new tab by the user.

comment:8 Changed 16 months ago by Lain_13

Since ABP already wrapping WebSocket, why don't wrap window.open as well? I'm already doing so for a few sites in my RU AdList JS Fixes and it works.

comment:9 Changed 16 months ago by trev

Wrapping window.open doesn't work in the same way, as established on https://stackoverflow.com/questions/6649742/changing-window-prototype-open-in-a-way-that-isnt-detectable-reversible such manipulation would be trivial for the website to revert.

comment:10 Changed 15 months ago by kzar

Is it possible we could use the transitionQualifiers and transitionType keys provided by chrome.webNavigation.onCommitted?

When I middle-click a link I get these values:

transitionQualifiers: [],
transitionType: "link"

But when I use window.open(...) I get these:

transitionQualifiers: ["server_redirect"]
transitionType: "link"

(Problem is I think onCommitted is after we block the popups at the moment, so we'd have to change the logic so that they weren't blocked until onComitted fired.)

comment:12 Changed 2 months ago by mapx

Event.isTrusted was already used here:
https://issues.adblockplus.org/ticket/3828

comment:13 Changed 5 weeks ago by mapx

another case:

Impossible to google the words "popunder" and "clickunder" when ABP is on. 
I was just reading an article about SEO, landing pages and ClickUnder ads 
and at one moment decided to search the word "ClickUnder" using the context
 menu of Google Chrome (right-click the selected words on the page). Seems 
to me it's not ok to recognize the simple text as clickunder or popunder...
Looking forward to ur feedback, thnx!

https://adblockplus.org/forum/viewtopic.php?f=10&t=54284

workaround:
@@||google.*/search?q=popunder$popup

comment:14 Changed 5 weeks ago by mapx

  • Cc mjethani added

comment:15 Changed 5 weeks ago by mapx

  • Description modified (diff)

comment:16 Changed 5 weeks ago by mapx

  • Description modified (diff)

comment:17 Changed 5 weeks ago by mjethani

We don't really get an Event object in the webNavigation API so we can't use Event.isTrusted

comment:18 Changed 5 weeks ago by mapx

As I posted above it seems uBo fixed such issue
https://github.com/gorhill/uBlock/commit/2660bee0d20e8355380b1b8c64973601514526cd

I tested the same (last) case in uBo and no issue here. (hmm ... wrong ... I still get a closed popup)

Last edited 5 weeks ago by mapx (previous) (diff)

comment:19 Changed 5 weeks ago by mapx

  • Cc arthur added

comment:20 Changed 5 weeks ago by mapx

Well, at least the filter above should be added to easylist.

Note: See TracTickets for help on using tickets.