1900730 - Selecting the 'Disable prefetching' option in UBlock Origin does not block prefetching

Status: RESOLVED DUPLICATE of bug 1861889

(Core :: Networking, defect, P2)

Description

[Ed]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

Enabled 'Disable pre-fetching' in UBlock Origin.

Actual results:

Nothing.

Expected results:

network.dns.disablePrefetch and network.dns.disablePrefetchFromHTTPS should have switched from false to true, and network.prefetch-next should have switched from true to false.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sunil Mayya]

Hey Ed,
Thanks for raising this bug.
Any strong reasons why you think this could be an issue with Firefox and not with UBlock origin?

Comment 3

[Ed]

Yes, see https://www.reddit.com/r/uBlockOrigin/comments/1d6tmck/comment/l711ajp/.

Comment 4

[Sunil Mayya]

I will check this if we have the same issue on other platforms.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Sunil,
I noticed this issue and I thought to provide you some context from a WebExtensions side in case that may be helpful context to have while you look into this:

• The WebExtensions API that ublock may be using is very likely to be browser.privacy.network.networkPredictionEnabled
• on the implementation side we can see which about:config prefs are expected to be changes when the networkPredictionEnabled API is used (and while network.dns.disablePrefetch is listed there already, network.dns.disablePrefetchFromHTTPS is not):
  • https://searchfox.org/mozilla-central/rev/aa9d148d5be3e7b606448f0b8da6e9f4fa43112f/toolkit/components/extensions/parent/ext-privacy.js#50-66

When I tried in a new nightly profile, where I have only install ublock origin and then checked about:config:

• network.dns.disablePrefetch was set to true as expected
• network.prefetch-next was set to false as expected
• network.dns.disablePrefetchFrom was NOT set to true (currenty expected given it is not part of the "network.networkPredictionEnabled" settings in the code linked above, but that seems to be likely missing because it was added after that setting was implemented and not added to it since then)

There is a precedence mechanism implemented by the ExtensionPreferenceManager/ExtensionSettingsStore which has to be taken into account, more than extension installed may want to control a browser setting but only one at the time can actually control it.

The first extension that uses the API to control the settings is going to be controlling it in practice, and extensions that may have be installed later will not be able to controll the same setting at the same time (but they would be tracked as next in the precedence list and so they would be expected to control the setting if the extension that is currently controlling it is disabled).

Extension code itself can actually check if they are successfully controlling the pref or not, e.g. connecting to ublock origin background page from about:debugging and then executing await browser.privacy.network.networkPredictionEnabled.get({}), e.g. in the vanilla profile where I tested it the result was { levelOfControl: "controlled_by_this_extension", value: false }

The other values that the return value may have are listed here in the API schema for "LevelOfControl": https://searchfox.org/mozilla-central/rev/aa9d148d5be3e7b606448f0b8da6e9f4fa43112f/toolkit/components/extensions/schemas/types.json#17-27

To pin point which is the extension currently controlling the setting, using ExtensionSettingsStore privileged internal from a Browser Console may turn out to be handy, e.g. the following snipped executed in the Browser Console related to a profile where we are hitting the issue:

• await ExtensionSettingsStore.getSetting("prefs", "network.networkPredictionEnabled") to get the currently controlling extension
  (in my vanilla profile the result was { key: "network.networkPredictionEnabled", value: false, id: "[e-mail]" })

• await ExtensionSettingsStore.getAllSettings("prefs", "network.networkPredictionEnabled") to get the precedence order for the
  settings and all extensions that would like to control the setting and which one is actually controlling it
  (in my vanilla profile the result was [{ enabled: true, id: "[e-mail]", key: "network.networkPredictionEnabled", value: false}])

As an additional side note:
For some browser settings there is UI in about:preferences pages for the user to see which is the extension actually controlling the setting, e.g. this is the case for the contextual identity feature (which is implicitly controlling the prefs to enable the experimental feature when an enabled extension uses it for the first time), but I think that the "network.networkPredictionEnabled" controlling extensions isn't going to be visible in about:preferences at the moment and that may be a source of confusion for the user with more than one extension controlling that pref (I'd guess it may be hit by users with multiple adblockers addons installed and enabled at the same time).

Comment 6

[Valentin Gosu [:valentin]]

Ed, could you maybe list all the other extensions you have installed?
And also try this in a new profile with only ublock Origin installed to make sure the explanation in comment 5 fully covers the issue you're seeing?

Comment 7

[Ed]

On a new nightly profile with UBO only:

• network.dns.disablePrefetch was set to true as expected

• network.dns.disablePrefetchFromHTTPS was not changed to true

• network.prefetch-next was set to false as expected

• network.dns.disablePrefetchFrom does not exist

• network.networkPredictionEnabled does not exist

Comment 8

[Ed]

Attachment: Addons_Nightly.txt

I have a LOT of add-ons!

Comment 9

[Sunil Mayya]

Thank you :luca for the detailed explanation and pointing to the bug.
Specifically about how the ExtensionPreferenceManager/ExtensionSettingsStore manages precedence from from multiple extensions.
I think we should first fix adding network.dns.disablePrefetchFromHTTPS as it is the obvious bug here.
We can then verify if there are other extensions that are making parallel accesses to the pref. However, if this is the case there cannot be much done from our end. The user needs to re-install the extension based on their priorities.

Comment 10

[mikhail]

https://github.com/arkenfox/user.js/issues/1870

network.dns.disablePrefetch is also the master switch of network.dns.disablePrefetchfromHTTPS.

Comment 12

[Valentin Gosu [:valentin]]

ni? me to look into the difference between the prefs and whether webext should flip both.