1903615 - Upgrading Firefox to version 127.0 and 127.0.1 each forced enabling recommending extensions/features

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[sworddragon2]

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

Steps to reproduce:

1. In about:preferences disable both settings "Recommend extensions as you browse" and "Recommend features as you browse".
2. Upgrade Firefox to version 127.0 or higher.

Actual results:

Both mentioned settings have been enabled after the upgrade.

Expected results:

Both settings should preserve their value through upgrades.

Additional details:

So far as I can see on looking through about:preferences all my other settings are untouched so I'm curious why only those 2 specific ones are enabled after each upgrade beginning with Firefox 127.0.

Comment 1

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

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

Comment 2

[Monica Chiorean]

I was able to reproduce the issue on Win11 upgrading from 126.0 to 127.0.1. Marking issue as new.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey pdahiya, did something change recently that might have caused this?

Comment 4

[Punam Dahiya [:pdahiya]]

Hi @mconley , AFAIK these prefs have stayed untouched for many releases. However these are synced by default

https://searchfox.org/mozilla-central/rev/e729cdd1537458f9268215c2ff6dddb231c3a6d9/browser/app/profile/firefox.js#1558

and might be leading to this issue on upgrade.

NI @mchiorean if you have sync enabled on the given profile before upgrade.

NI @markh for feedback who has looked into similar issues in past https://bugzilla.mozilla.org/show_bug.cgi?id=1731249 . Thanks!

Comment 5

[Monica Chiorean]

No I did not have any account configured on Win11, for sync.

Comment 6

[sworddragon2]

I'm also not using an account with my Firefox installation (and never had) so the changed settings could not have be caused by some synchronization logic (unless there is a very specific bug that falsely syncs while offline).

Comment 7

[Mark Hammond [:markh] [:mhammond]]

Sure sounds like this isn't related to sync.

Comment 8

[Punam Dahiya [:pdahiya]]

Tried on Windows 11 Pro Build Number 22631 and so far recommend features and extension settings stays restored along with other custom settings under Tabs when updating Firefox via Menu -> Help -> About Firefox -> Update from 127.0 to latest 127.0.2 .

Firefox 128 launches tomorrow, will try updating Firefox to Fx 128 and see how it goes thanks

Comment 9

[bsadowski1]

(In reply to Punam Dahiya [:pdahiya] from comment #8)

Tried on Windows 11 Pro Build Number 22631 and so far recommend features and extension settings stays restored along with other custom settings under Tabs when updating Firefox via Menu -> Help -> About Firefox -> Update from 127.0 to latest 127.0.2 .

Firefox 128 launches tomorrow, will try updating Firefox to Fx 128 and see how it goes thanks

This is still happening with the latest stable (128.0.0)

Comment 10

[Punam Dahiya [:pdahiya]]

I am able to replicate the issue by following below steps

1. Install Fx126 on windows 11 using full installer
2. Go to about:preferences uncheck both settings "Recommend extensions as you browse" and "Recommend features as you browse". (correspond to browser.newtabpage.activity-stream.asrouter.userprefs.cfr.addons and browser.newtabpage.activity-stream.asrouter.userprefs.cfr.features)
3. Go to about:profiles -> open folder next to profile in use -> open pref.js , both above pref sets to false as expected
4. Go to Menu -> Help -> About Firefox -> Click Update
5. Firefox restarts after updating to latest version.
6. Opening about:preferences has these two settings checked . Opening prefs.js inside profile folder shows these two prefs missing (see attached)

Other prefs such as browser.newtabpage.activity-stream.showSearch and browser.newtabpage.activity-stream.showSponsored also manually updated in about:preferences are successfully retained

Comment 11

[Punam Dahiya [:pdahiya]]

Attachment: pref before and after update.png

Comment 12

[Punam Dahiya [:pdahiya]]

Underlying Issue seems to be failing to write these prefs state to prefs.js on Firefox update. @mchiorean if its possible will be great to get regression range as that can help track down the issue. thanks!

Comment 13

[Punam Dahiya [:pdahiya]]

Settings code in about:preferences that renders these prefs hasn't been touched in a while.
https://searchfox.org/mozilla-central/rev/a7e19af54ce40c7f2d0cb0457d3b12c279fe0f68/browser/components/preferences/main.inc.xhtml#773
https://searchfox.org/mozilla-central/rev/a7e19af54ce40c7f2d0cb0457d3b12c279fe0f68/browser/components/preferences/main.js#94

Not entirely sure how Update flow uses or updates prefs.js. Doesn't look related but noticed pave over migration fix done here touches prefs.js @mconley does FirefoxProfileMigrator kicks in during regular firefox updates? Thanks!

Comment 14

[Monica Chiorean]

(In reply to Punam Dahiya [:pdahiya] from comment #12)

Underlying Issue seems to be failing to write these prefs state to prefs.js on Firefox update. @mchiorean if its possible will be great to get regression range as that can help track down the issue. thanks!

I tried upgrading from 110.0, 119.0, 123.0, 125.0 they all upgrade to 127.0 and then to 128.0 and the problem reproduces on all of them. There is a watershed at 127.0 so I could not find a regression.

Comment 15

[Punam Dahiya [:pdahiya]]

(In reply to Monica Chiorean from comment #14)

(In reply to Punam Dahiya [:pdahiya] from comment #12)

Underlying Issue seems to be failing to write these prefs state to prefs.js on Firefox update. @mchiorean if its possible will be great to get regression range as that can help track down the issue. thanks!

I tried upgrading from 110.0, 119.0, 123.0, 125.0 they all upgrade to 127.0 and then to 128.0 and the problem reproduces on all of them. There is a watershed at 127.0 so I could not find a regression.

Thanks @mchiorean for checking, considering nature of this issue will reach out to cross functional team leads to get feedback and update.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

Hi! No, the migrator code is not expected to kick in during a normal update.

Comment 17

[Dave Townsend [:mossop]]

As far as we can tell this only happens on Windows and only when performing an automatic update. Installing a new version over the top and then running does not show the behaviour. Also letting the update happen but cancelling the new version in early startup and then starting does not show the behaviour.

By overriding the update server it appears that this was introduced in 127 and happens with updating to that version or any later version. Automatically updating from v90 to v126 does not exhibit the behaviour while updating from v90 to v127 does.

However, bizarrely, performing an automatic update from a custom build of 127 to the official build of 128 does not show the behaviour. Likewise an automatic update from a custom build of 127 to a custom build of 128 does not show the behaviour.

Comment 18

[Dave Townsend [:mossop]]

I believe I have isolated its cause as being a bug causing the background task that registers the default agent to use the default profile instead of a temporary profile.

When we restart to apply an application update we set the XRE_PROFILE_PATH environment variable to the current profile to ensure the new instance uses the same profile (which may not be the default profile). When we eventually get to spawning the background task to register the default agent task I believe that that environment variable is still set and so carries through to the background task process, this causes us to use that profile for the task as opposed to the background task specific profile logic which comes later.

Why this resets certain preferences is that background tasks load different pref defaults, when these defaults match the current user set values in the profile they are effectively reset

Comment 19

[sworddragon2]

(In reply to Dave Townsend [:mossop] from comment #18)

Why this resets certain preferences is that background tasks load different pref defaults, when these defaults match the current user set values in the profile they are effectively reset

So if I'm understanding this right only those 9 preferences can possibly reset in this build and as far as I can tell from those 9 preferences only the 2 ones mentioned in this ticket (recommending extensions/features) are ones that are common settings that might be changed by an user (possibly also the only 2 ones found in the options dialog).

Comment 20

[Dave Townsend [:mossop]]

(In reply to sworddragon2 from comment #19)

(In reply to Dave Townsend [:mossop] from comment #18)

Why this resets certain preferences is that background tasks load different pref defaults, when these defaults match the current user set values in the profile they are effectively reset

So if I'm understanding this right only those 9 preferences can possibly reset in this build and as far as I can tell from those 9 preferences only the 2 ones mentioned in this ticket (recommending extensions/features) are ones that are common settings that might be changed by an user (possibly also the only 2 ones found in the options dialog).

There are also these preferences. The devtools ones there are commonly used by developers but other than those yes I think the impact to users is restricted to the two settings you spotted.

Comment 21

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1903615 - Invoke post-update process with minimal/empty environment. r?bytesized

When Firefox relaunches itself to finish updating, it sets a number of
environment variables control the relaunch. Background tasks obey
those environment variables (by design), but that is causing a
problem. On Windows, post-update invokes the WDBA task
to (re-)register itself, and that is running in the default browsing
profile (gasp!), and that is flipping select preferences in the
default browsing profile (double gasp!). Invoking the post-update
process with a minimal/empty environment should avoid this issue.

The callback application will continue to be invoked with the current
non-minimal environment.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/423a9b8fd2f1
Invoke post-update process with minimal/empty environment. r=bytesized,application-update-reviewers,spohl

Comment 23

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/423a9b8fd2f1

Comment 24

[Monica Chiorean]

I am still able to reproduce the issue on Win11x64. I updated from build 129.0b9.exe to 1330.0b1 and both options "Recommend extensions as you browse/Recommend features as you browse" are checked after update. Is this expected? thank you.

Comment 25

[Masatoshi Kimura [:emk]]

(In reply to Monica Chiorean from comment #24)

I am still able to reproduce the issue on Win11x64. I updated from build 129.0b9.exe to 1330.0b1 and both options "Recommend extensions as you browse/Recommend features as you browse" are checked after update. Is this expected? thank you.

I think it's expected because 129 to 130 updates use the updater from the 129 installation that is not patched yet. I verified that "Recommend extensions as you browse" and "Recommend features as you browse" are retained across 130.0b1 to 130.0b2 update.

Comment 27

[Monica Chiorean]

It seems that updating from 130.0b1 to 130.0b2 works correctly. Waiting for 130.0 release to mark it as verified. Thank you.

Comment 28

[mjb]

Someone is saying that its broken on 130 and 131 beta https://old.reddit.com/r/firefox/comments/1f920kr/every_major_update_these_two_settings_are_turned/lliuf16/

Comment 29

[Masatoshi Kimura [:emk]]

It's expected that 129 to 130 still re-enables the settings. Regarding 131 beta, it depends on which version it was updated from.

Comment 30

[:glob ✱]

(In reply to mjb from comment #28)

Some [slur] is saying that its broken on 130 and 131 beta https://old.reddit.com/r/firefox/comments/1f920kr/every_major_update_these_two_settings_are_turned/lliuf16/

This is a polite reminder that Bugzilla is our professional working environment as well as our issue tracker. I encourage you to review our Community Participation and Bugzilla Etiquette guidelines.

Comment 31

[mjb]

(abusive deleted)

Comment 32

[sworddragon2]

(In reply to Masatoshi Kimura [:emk] from comment #29)

It's expected that 129 to 130 still re-enables the settings.

Yes, every upgrade to (including) version 130.0 has still enabled those settings since I reported the issue. And now that version 130.0.1 is available I took the opportunity to test if all is working fine now:

• The settings "Recommend extensions as you browse" and "Recommend features as you browse" have been manually disabled again after upgrading Firefox to version 130.0 around 2 weeks ago and they were still disabled on this profile before I did the upgrade to version 130.0.1 a few minutes ago.
• After doing the upgrade via "Application menu -> Help -> About Firefox" to version 130.0.1 and doing a restart of Firefox those both settings are still disabled.

So all seems to be working fine now.

Comment 33

[Nick Alexander :nalexander [he/him]]

(In reply to sworddragon2 from comment #32)

(In reply to Masatoshi Kimura [:emk] from comment #29)

It's expected that 129 to 130 still re-enables the settings.

Yes, every upgrade to (including) version 130.0 has still enabled those settings since I reported the issue. And now that version 130.0.1 is available I took the opportunity to test if all is working fine now:

• The settings "Recommend extensions as you browse" and "Recommend features as you browse" have been manually disabled again after upgrading Firefox to version 130.0 around 2 weeks ago and they were still disabled on this profile before I did the upgrade to version 130.0.1 a few minutes ago.
• After doing the upgrade via "Application menu -> Help -> About Firefox" to version 130.0.1 and doing a restart of Firefox those both settings are still disabled.

So all seems to be working fine now.

Thanks for confirming that this appears fixed, and many apologies for the churn -- a truly unexpected interaction was underneath it all.