Closed Bug 1430590 Opened 2 years ago Closed 2 years ago

about:preferences does not update immediately when an extension changes Tracking Protection

Categories

(Firefox :: Preferences, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 59
Tracking Status
firefox59 --- fixed

People

(Reporter: bsilverberg, Assigned: bsilverberg)

References

Details

Attachments

(1 file)

Now that bug 1390161 has landed, about:preferences shows when an extension is controlling Tracking Protection (TP). However, if you are on the about:preferences page when an extension that controls TP is either installed or uninstalled/disabled, the value of TP is not updated. You need to refresh the about:preferences page in order to display the new value.

This is consistent with the behaviour of about:preferences when you change a preference manually, e.g., via about:config. I'm not particularly concerned about the case of an extension being installed, as it seems pretty edge-casey that a user will already be looking at about:preferences#privacy when an extension that controls TP is installed (although certainly not out of the question), but I am a bit concerned about the case where a user disables an extension via the button on the about:preferences page, and does not immediately see the new values reflected.

I think we should fix at least the disable case, and ideally both install/enable and uninstall/disable.

Mark and/or Markus, what do you think?
Flags: needinfo?(mstriemer)
Flags: needinfo?(mjaritz)
That sounds odd... I would expect everything to update whenever something changes. (No matter if preferences is open, or not.)
I agree that the disable case seam more problematic.
Flags: needinfo?(mjaritz)
I think the expected behaviour in about:preferences is actually that it updates if you modify about:config with preferences open. If you look at some other fields they're tied to the preference directly (like the checkboxes under Address Bar [1]) and update based on pref changes.

I'm guessing this is happening because there are two prefs controlling the 3 radio buttons which is kind of weird. The function that sets the value should get called when either of the prefs changes, I think.


[1] https://searchfox.org/mozilla-central/rev/137f1b2f434346a0c3756ebfcbdbee4069e15dc8/browser/components/preferences/in-content/privacy.xul#250-252
Flags: needinfo?(mstriemer)
Priority: -- → P3
Thanks Mark. It does seem like the expected behaviour is as you describe. It just so happens that it's not working specifically for the TP controls. I took a look at the older version of the screen, from before both bug 1390161 and bug 1379338 landed, and it too had the same issue. It looks like the TP controls never updated when the pref was changed manually - I guess it was an oversight that was never discovered before.

Therefore, this isn't really a WebExtensions bug, but rather a feature that's been missing from about:preferences#privacy for a long time, possibly forever. I'm going to move this bug to the proper component, and I'm not sure who should fix it. I believe that Jared is the triage owner for the component, so let's see what he thinks. 

I can probably do the work if need be, as it doesn't look like too big of a deal, but if someone in the area responsible wants to take it that's fine too. I'm also not sure how to prioritize this, particularly considering that it's a bug that's likely been around forever, although with the changes from bug 1390161 landing, it's more likely that this bug could affect a user. The case where a user chooses to disable an extension that is controlling TP, and the UI doesn't update to show the correct values, seems like something we should fix.
Assignee: bob.silverberg → nobody
Component: WebExtensions: Frontend → Preferences
Priority: P3 → --
Product: Toolkit → Firefox
Flags: needinfo?(jaws)
You will want to create lazyPreferenceGetters for the two prefs at https://hg.mozilla.org/mozilla-central/rev/85eb82400669#l3.20 and pass `_updateTrackingProtectionUI()` as the onUpdate function.

The tracking protection items are showing this bug because their state is only set up on page load. Widgets that use the preference="" attribute are live and will auto-update on preference changes.
Flags: needinfo?(jaws)
Thanks Jared. I noticed that after bug 1379338 landed watching for pref changes seems to be done differently, so I've created a patch that seems to work and uses the new method. I'll flag you for review.
Assignee: nobody → bob.silverberg
Priority: -- → P3
Comment on attachment 8943033 [details]
Bug 1430590 - Watch for and respond to TP pref changes on about:preferences,

https://reviewboard.mozilla.org/r/213298/#review219050
Attachment #8943033 - Flags: review?(jaws) → review+
Pushed by bsilverberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/142e0c92435a
Watch for and respond to TP pref changes on about:preferences, r=jaws
https://hg.mozilla.org/mozilla-central/rev/142e0c92435a
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
You need to log in before you can comment on or make changes to this bug.