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

Incompatibility with Wikiwand on Firefox #158

Open
Luracasmus opened this issue Jul 29, 2024 · 8 comments
Open

Incompatibility with Wikiwand on Firefox #158

Luracasmus opened this issue Jul 29, 2024 · 8 comments
Labels
Firefox Specific to Firefox mv3 hardship

Comments

@Luracasmus
Copy link

Luracasmus commented Jul 29, 2024

Using uBOL with Basic Optimal or higher filtering mode prevents the Wikiwand extension from redirecting links going to wikipedia.org

@stephenhawk8054
Copy link
Member

What are the steps to reproduce the issue?

@Luracasmus
Copy link
Author

Luracasmus commented Jul 29, 2024

I have the latest versions of both extensions installed on Firefox 128.0.2, Windows 11 x64 (MSIX), with what I think is default settings (except for using Optimal instead of Basic filtering mode)

To reproduce the issue i simply search for anything that shows results from Wikipedia, and click on one of the results from wikipedia.org

With only Wikiwand installed, I'm automatically redirected to the Wikiwand equivalent of the same article, but with uBOL enabled with Basic Optimal or higher filtering mode, this doesn't happen

@garry-ut99
Copy link

but with uBOL enabled with Basic or higher filtering mode

Are you sure, because I'm unable to reproduce on Basic, I can reproduce only on "Optimal" or "Complete".

Also the issue is gone after disabling:

  • "Ads, trackers, miners, and more"
  • and "AdGuard URL Tracking Protection"
    (it's not enabled by default, but in case one had it enabled manually)

@gorhill
Copy link
Member

gorhill commented Jul 30, 2024

The issue doesn't exist for Chromium, it affects only Firefox.

The issue exists when using either Optimal or Complete mode as the default one, and doesn't exists when using Basic mode as the default one. Modifying the per-site mode makes no difference.

The issue arises because of the DNR rule to remove query parameters:
https://github.com/uBlockOrigin/uBOL-home/blob/main/firefox/rulesets/removeparam/default.json#L5

That DNR rule is the result of grouping privacy-related filters such as $removeparam=__hsfp -- there are over 100 of these coalesced into that one DNR rule.

The rule's condition is {"resourceTypes":["main_frame","sub_frame","xmlhttprequest"]}, and thus Firefox considers that the rule matches any of these request types regardless of the URL, so https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy in the current case.

Firefox's assessment that a DNR rule match occurs causes it to skip passing the request to webRequest listener used by Wikiwand:
https://searchfox.org/mozilla-central/rev/e637cd67f98ed4272d13a96db9a7674689122dcb/toolkit/components/extensions/webrequest/WebRequest.sys.mjs#1031-1033

The issue doesn't exist when default mode is Basic because in such case the removeparam rules are not registered into the DNR engine.

The fact that the issue doesn't exist in Chromium suggests that maybe the DNR code in Firefox needs to be adjusted.

Regarding uBOL, a solution would be to not coalesce the over 100 $removeparam=[param] filters into a single DNR rule, but rather into as many DNR rules in the form [param]$removeparam=[param] -- but I am not very motivated to go that route, it would be uBOL having to mind implementation details of a specific DNR engine, at the expense of no longer efficiently coalesce many filters into as few DNR rules as possible.

uBO's own filtering engine does optimize to efficiently store filters such as $removeparam=[param] by using the [param] component as token/hash to ensure fast lookup of matching filters given a specific URL, I would expect a DNR engine to be similarly optimized in the long run.

@gorhill gorhill added the Firefox Specific to Firefox label Jul 30, 2024
@Luracasmus
Copy link
Author

Luracasmus commented Aug 3, 2024

but with uBOL enabled with Basic or higher filtering mode

Are you sure, because I'm unable to reproduce on Basic, I can reproduce only on "Optimal" or "Complete".

Also the issue is gone after disabling:

* "Ads, trackers, miners, and more"

* and "AdGuard URL Tracking Protection"
  (it's not enabled by default, but in case one had it enabled manually)

It turns out I had switched the filtering mode to Basic only for the search engine, which didn't get saved as per-site overrides are only available for completely disabling filtering

I had the global filtering mode set to Optimal, and the only enabled filter list was "Ads, trackers, miners, and more"

@gorhill
Copy link
Member

gorhill commented Aug 3, 2024

per-site overrides are only available for completely disabling filtering

Per-site overrides are available for all filtering modes.

@Luracasmus
Copy link
Author

Luracasmus commented Aug 3, 2024

Wait, they are?
Where are they listed?

Also, apologies for not doing more research before writing lol

@gorhill
Copy link
Member

gorhill commented Aug 3, 2024

They are not listed, the popup panel will reflect whichever mode has been last selected for the current site.

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

No branches or pull requests

5 participants