2028331 - Firefox Sync does not handle mismatched default prefs

Status: UNCONFIRMED

(Firefox :: Sync, defect, P3)

Description

[Hoshino Lina]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

Reported downstream here: https://bugzilla.redhat.com/show_bug.cgi?id=2020436
And also here: https://discussion.fedoraproject.org/t/fedora-start-constantly-hijacking-firefox-home-page/156154/26
(Many other user reports of the same across Reddit/etc)

When Firefox installs on different systems have different default prefs, such as a different default home page, this interacts very poorly with Firefox Sync.

What seems to happen is that:

• Firefox is installed on a system with a non-(Firefox upstream)-default home page set at the system level (browser/defaults/preferences/foo.js)
• The user changes the home page to Firefox Home
• Sync synchronizes the change to another system with stock Firefox
• As part of that, Sync or Firefox recognizes that the home page pref is now the default on the second system, and deletes the user pref entirely, which is a no-op on the second system
• The deletion is synced back to the first system
• The home page reverts to the system level default on the first system

This is a general issue with prefs that have different defaults on different systems, it seems.

Note: There seem to be other bugs related to prefs resetting to their defaults too (unrelated to Sync, at least reportedly), which is causing much user confusion around this general issue. Users believe the distributor is intentionally resetting their preference on upgrades and things like that, it's a mess.

Comment 1

[Mark Hammond [:markh] [:mhammond] [PTO until Sept 7]]

This is a tradeoff with no great outcomes or alternatives. When a pref changes to the default, explicitly marking it as such is the only way to handle prefs which have the "real" default value change over time. For example, a preference to enable a new feature often starts with a default of false, then defaults to true. It would be a bad outcome if sync forced the preference to forever remain false.

Preference syncing does however have support for making certain prefs work that way - once they have been changed to a non-default value, the value sticks even when the default changes. Here are some comments about how it works. We use this for preferences which have different defaults on different platforms - eg, the autoscroll preference - before that, those preferences demonstrated exactly what you describe above. The other alternative is obviously to just avoid syncing those preferences - maybe forks which change the defaults but expect to be able to sync with official firefoxes should consider disabling the syncing of the prefs they change?

Comment 2

[Hoshino Lina]

For example, a preference to enable a new feature often starts with a default of false, then defaults to true. It would be a bad outcome if sync forced the preference to forever remain false.

I think the missing "bit" of information here is intentional user change. If a user sets the pref on any browser, then I would expect that to be synced forever. That way, prefs which are the default and have never been touched would flip as needed, but prefs which have been reverted to the default stick. I think that makes more sense, at least for UI-visible prefs, than silently considering a change to the default as "unset".

maybe forks which change the defaults but expect to be able to sync with official firefoxes should consider disabling the syncing of the prefs they change?

This is not a fork, it's the official Firefox package for Fedora (branded and all, my understanding is this is all approved), just with the default homepage set systemwide (not via code patch, just via a .js drop-in override). AIUI this is the same mechanism as admin policy overrides and supported for upstream Firefox builds too.

Since this pref itself is not synced, it sounds like Firefox needs to add this pref upstream for the behavior to be what users expect. The prefs that Fedora overrides are here: https://src.fedoraproject.org/rpms/firefox/blob/rawhide/f/firefox-redhat-default-prefs.js

Is there any chance of adding at least browser.newtabpage.pinned and browser.startup.homepage to sync-seen? Otherwise I guess Fedora could disable them in "sync", but then the home page would not be synced at all, which is annoying.

Comment 3

[Hoshino Lina]

I'm confused about the behavior of the "sync" control prefs. If Fedora were to set services.sync.prefs.sync.browser.startup.homepage to false, since control prefs are (apparently) also synced, wouldn't that disable homepage syncing across all user Firefox instances forever? That seems very undesirable...

Comment 4

[Mark Hammond [:markh] [:mhammond] [PTO until Sept 7]]

I think the missing "bit" of information here is intentional user change. If a user sets the pref on any browser, then I would expect that to be synced forever.

That is indeed the intent of the "seen-pref" - whenever it is seen as not-the-default, we stick with that.

Is there any chance of adding at least browser.newtabpage.pinned and browser.startup.homepage to sync-seen?

I guess you could argue that makes sense for homepage. Less clear about pinned though. I haven't thought through the implications of making more prefs work this way (or indeed, all of them?).

I'm confused about the behavior of the "sync" control prefs. If Fedora were to set services.sync.prefs.sync.browser.startup.homepage to false, since control prefs are (apparently) also synced, wouldn't that disable homepage syncing across all user Firefox instances forever? That seems very undesirable...

Yeah. I was more thinking they could set the control pref to the "seen" value. Not sure how that would turn out though, but we could probably arrange for that to be sane.

Comment 5

[Hoshino Lina]

Downstream I'm going to make the homepage default override optional (a separate package), so affected users can uninstall it. However, that's really just a workaround for the underlying issue.

I was more thinking they could set the control pref to the "seen" value. Not sure how that would turn out though, but we could probably arrange for that to be sane.

How would that work? Or do you mean just setting seen-pref to true ahead of time? I'm not sure that is a good idea since I think it means if anyone connects Fedora Firefox to Sync, it will push the Fedora home page to all their other devices... which is going to feel even more invasive.

Comment 6

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:bdk, could you have a look please?

For more information, please visit BugBot documentation.