Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Middle clicking on a link triggers popup rule, but only since updating to webext-hybrid. #2919

Closed
Okamoi opened this issue Aug 29, 2017 · 9 comments

Comments

@Okamoi
Copy link

Okamoi commented Aug 29, 2017

Describe the issue

When middle clicking on a link that directs to a site blocked from opening pop ups by a filter, this link does not open. It is treated like a pop up instead of a new tab, and this only happens since 1.13.10.

One or more specific URLs where the issue occurs

anilinkz.to/anime-list

Steps for anyone to reproduce the issue

  1. Enable (FRA) Liste FR, or alternatively add custom filter ||anilinkz.$first-party,popup
  2. Open uBO's logs
  3. Go to anilinkz.to/anime-list
  4. Middle click on any anime on the list
  5. See how the tab is killed and logs report the filter described above as the culprit

Your settings

  • OS/version: Windows 7 64-bit
  • Browser/version: Firefox 55.0.2 32-bit
  • uBlock Origin version: 1.13.10
@gorhill
Copy link
Owner

gorhill commented Aug 29, 2017

It has been a long time I played with that code, but I believe uBO was disregarding that the link was clicked by the user because it was not possible on Chromium to detect whether a click was the result of the user clicking, or whether it was programmatically triggered by nasty javascript code.

Looking at current MDN documentation, it says that the isTrusted property is now supported by Chromium, since version 46. So I guess I can just go ahead and now take into account the isTrusted property.

@Okamoi
Copy link
Author

Okamoi commented Aug 29, 2017

Sounds good! Do you have some automated test cases or something to help you test for feature parity between the legacy version of uBO and the WebExt ?

Since that one seems to be a port from the Chrome version, there could be several such tiny things, some of which unnoticeable by users. And manual testing sounds like a daunting task...

@gorhill gorhill closed this as completed in 2660bee Sep 5, 2017
@gomoku
Copy link

gomoku commented Sep 6, 2017

The issue still occurs (on a fresh browser profile + uBO):

FF 55.0.3 32bit + uBO v1.14.9b0
FF 56.0b9 64bit + uBO v1.14.9b0
Opera 47.0.2631.71 (PGO) 64bit + uBO v1.14.9.0
Windows 7 SP1 U 64bit

@mapx-
Copy link

mapx- commented Oct 4, 2017

See
https://forums.lanik.us/viewtopic.php?p=125336#p125336

If you middle click the first link the tab opens and then closes due to this filter:
||iqoption.com/land/$third-party,popup

As you arrive on that page through isTrusted action it shouldn't be considered as third-party object

@gorhill
Copy link
Owner

gorhill commented Oct 4, 2017

When I click the link, a new tab opens with Google Search page. Without an actual repro case, I can't investigate.

@mapx-
Copy link

mapx- commented Oct 4, 2017

When I middle click the link I see this in the logger:
pop1

@gorhill
Copy link
Owner

gorhill commented Oct 4, 2017

What link exactly? I tried the one you posted above, "first link", and can't reproduce any closed popup:

a

But anyways, from your screenshot, the popup was properly closed, because the URL of the popup changed from the one clicked by the user, which is what the fix is here. The 3rd-partyness is properly evaluated in this case, the 1st party is still the URL of the tab from where the popup was opened.

@mapx-
Copy link

mapx- commented Oct 4, 2017

Weird ..: if I middle click https://affiliate.iqoption.com/redir/?aff=2354 it means I'm already on the iqoption domain, right ? Then the redirect seems to transform itself in https://iqoption.com/land/regulated/en/ triggering this filter:
||iqoption.com/land/$third-party,popup

How could be third-party if first landed on the same domain ? Probably I'm missing something ?!

@gorhill
Copy link
Owner

gorhill commented Oct 4, 2017

The party-ness is always opener tab vs opened tab, regardless of redirection (however this redirection happens). The opener tab in the current case is always github.com -- that is my understanding of popup filter option.

If I understand the case here, the reporter on EasyList forum argues that the redirection to same domain as the trusted URL's one should not trigger popup filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants