Firefox package is open for provenpackagers, please commit the change to rawhide and build it. I'll merge it later to other branches. I saw the pull request but it conflicted with other ones. Also I'm not getting notifications about firefox pull requests (no idea why, maybe due to gecko-maint@ alias) so I hit the active request rather randomly.

Hello Martin and thanks for your reply,

I'm afraid I am a bit confused though, which pull request are you talking about that you saw? 
I didn't create any. Also with regards to prpovenpackagers, I assume that is a role one can get:
as I haven't built any official fedora or RedHat packages I could think of, I don't think I have that; 
and if I have it, I'm am a bit worried about how I got it.

There is of course a chance that someone else already started to work on fixing that. That would be nice, but that would not be me.

Thanks and kind regards,

Christian

It's https://src.fedoraproject.org/rpms/firefox/pull-request/68
Okay, just attach the patch here and I'll merge it to master.
Thanks.

Created attachment 2081121 [details]
Patch against the file in rawhide, should work for other versions, too

A proposed patch file, I went a bit further than the original pull request you linked and changed everything except auto-update (which fedora / RedHat probably really doesn't want the user to override) to be overrridable by user choices.

Note: I am not a packager, I don't know in detail that what I am doing is right, someone with more experience should probably test that.

Also if you need a different patch format, let me know; best with the diff parameters you'd like.

Thanks and kind regards

Added to git, Thanks.

FEDORA-2025-8141e309e9 (firefox-136.0.2-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-8141e309e9

I'm not sure this actually works as-is. openQA testing indicates that it does not, because we're now seeing the "make firefox your default browser" nag screen that should be disabled by setting browser.shell.checkDefaultBrowser to false.

I *think* I looked into this before and figured out that you can't use defaultPref in these .js files, you can only use it in AutoConfig .cfg files. I'm not 100% sure, but I *think* that's the issue here.

Adam, thanks for looking into it - will check that while creating a next update this/next week.

Reopening.

Thanks a lot you two for looking into it.

In this case I'd recommend fedora switches over to proper Autoconfig files.
From what I gather at https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig  the syntax is the same, so this should be fairly straightforward, apparently for Linux one uses https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson  this

I have no settings overridden after the update. How can this be reproduced, please explain again?

(In reply to Christian from comment #10)
> Thanks a lot you two for looking into it.
> 
> In this case I'd recommend fedora switches over to proper Autoconfig files.
> From what I gather at
> https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig 
> the syntax is the same, so this should be fairly straightforward, apparently
> for Linux one uses
> https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson 
> this

Why build some kind of crutches if everything works fine? Did you even reproduce your bug yourself?

(In reply to mikhail from comment #11)
> I have no settings overridden after the update. How can this be reproduced,
> please explain again?

It has to be one of the settings you find in the linked file / commit.

An easy way to reproduce is to change toe start page of firefox from an URL to the firefox default overview.

This will be changed to https://start.fedoraproject.org

And yes, it's obviously reproducible for me, else I wouldn't have reported this.
Note that the behaviour we are seeing is also what mozilla says is and should be the behaviour.

My prefs.js:

===
user_pref("browser.newtabpage.pinned", "[]");
user_pref("browser.startup.homepage", "about:home");
user_pref("network.trr.mode", 3);
===

And nothing has changed for me after the update.

(In reply to mikhail from comment #14)
> My prefs.js:
> 
> ===
> user_pref("browser.newtabpage.pinned", "[]");
> user_pref("browser.startup.homepage", "about:home");
> user_pref("network.trr.mode", 3);
> ===
> 
> And nothing has changed for me after the update.

Yes, as per what I wrote and what I suggested we change is that "user_pref" is used instead of "pref".
Current versions, before the fix, use "pref". AS per the mozilla documentation, "pref" will override the user, "user_pref" won't.

Yours works because it's the fix people have suggested.
It's not the current state in most fedora versions, which still uses "pref", and thus overrides.

You yourself don't understand what you're writing about. I suggest closing the bug.

FEDORA-2025-fb643ab7e9 (firefox-136.0.3-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-fb643ab7e9

I'm not sure that update should be marked as fixing this bug, as all it does is revert the initial attempt to fix it. It doesn't try again to fix it differently.

(In reply to Adam Williamson from comment #18)
> I'm not sure that update should be marked as fixing this bug, as all it does
> is revert the initial attempt to fix it. It doesn't try again to fix it
> differently.

/etc/firefox/pref/
/etc/firefox/defaults/pref/

Do you mean pref settings for the admin in these directories? Or what? How to reproduce this?
To fix something you need to know what to fix.

The problem this bug is about is:

We implement some distro-specific overrides of upstream Firefox default config settings in the file https://src.fedoraproject.org/rpms/firefox/blob/rawhide/f/firefox-redhat-default-prefs.js , which gets installed as /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js . Users report that the way we do this means that they cannot then override *those* preferences permanently; if they change one of those config settings, it is set back to our *distribution* value the next time Firefox is launched or the next time the Firefox package is updated (I'm not sure which). We want to fix this so that our distribution defaults are used *if the user does not change the setting*, but if the user changes the setting, their choice should be kept and never overridden back to our distribution default.

Martin tried to do this in https://src.fedoraproject.org/rpms/firefox/c/1b3593d295e90594b4c04e9485d2cf298c458019?branch=rawhide by changing that file to use `defaultPref()` instead of `pref()`, but in testing it looks like that did not achieve the desired effect. Instead, it just made them not take effect *at all*, so on a clean first run of Firefox, you got the *upstream* default values for all those preferences, not our downstream distribution defaults.

In the latest build, he has reverted back to the previous status quo, where our distro-level defaults work, but also prevent users overriding them.

(In reply to Adam Williamson from comment #20)

Read above
https://bugzilla.redhat.com/show_bug.cgi?id=2353895#c14

I have been using Fedora Xfce for 3 years and I don't have any overrides.

FEDORA-2025-fb643ab7e9 (firefox-136.0.3-1.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

If the overrides are not always applied, that would be an interesting case to maybe check out and potentially report back to upstream, as per https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig the "pref(prefName, value) – sets the user value of a preference. This function explicitly sets the preference as a user preference. That means that if the user has changed the value, it will get reset every time the browser is started." should do exactly that.

Also if browser.shell.checkDefaultBrowser  is the one misbehaving but otherwise it works, it would probably be an acceptable solution for now to leave that thing hard-set as "pref" for now, but change other settings to "userPref" so while they might not always get applied, the users can override them. And it's probably something we should also report upstream.

Christian: the point is that this file is *not*, AFAICT, an AutoConfig file. So that doc does not actually apply to it. If it was an autoconfig file and those docs applied, then changing them to defaultPref should have worked.

(In reply to Adam Williamson from comment #24)
> Christian: the point is that this file is *not*, AFAICT, an AutoConfig file.
> So that doc does not actually apply to it. If it was an autoconfig file and
> those docs applied, then changing them to defaultPref should have worked.

Yep, I did read that, the answer was more to both confusion on how what mikhail reported could happen, plus why the change would behave like that for the default browser nag window.
As previously mentioned, I am all in favour of migrating to a proper autoconfig file

Kind regards,

Christian

This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15.

Fedora Linux 41 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Is anyone actually experiencing this willing to help debug *what* is actually causing this behavior?

This keeps being reported by users, but so far absolutely no one has sat down and tried to figure out what makes some systems different and makes this bug happen. It happens for some people, not for others, and the people for whom it happens keep wrongly assuming it happens for everyone. And in the end nothing gets fixed.

I have tried going all the way back to F39 Firefox, setting the home page, then opening the profile in current, and some intervening versions. I have never seen the home page reset, ever. Nor in my regular Firefox usage on Fedora for several years. Yet for some people it resets on every update.

Please, someone who is actually hitting the bug needs to sit down and actually help track this down. Profile snapshots between updates would help. Maybe it's an environment thing. Maybe it's a race condition. I have no idea.

The solution is not to randomly change the way the prefs file is laid out (even if that could fix it by accident, it would not root cause the problem). The solution needs to start by identifying *what* causes this behavior in the first place, and getting a working set of repro steps. I volunteer to handhold whoever wants to help through getting a repro case or any kind of information we can use to track this down. I'm good at tracking down this kind of stuff, but I need a repro, because never in my life have I experienced this personally.

So far there is a semi known condition of Firefox Sync behaving badly with the specific case of about:home (workaround: set about:home#, I opened an upstream bug about this), but some people say it happens without Sync enabled. We need to figure out why.

@develop are you still seeing this? Would you be willing to help? I'm available on Matrix and various other platforms for real-time chat.

Hi Lina, 

(un)fortunately I can currently not reproduce the bug, but next time I can I will gladly assist in trying to find out what the root cause is / what to do in order to be able to reproduce it. 

I do know that in the past I didn't always see that behaviour, but it would return sooner or later, so let's hope it will, and then we can find and fix the cause.

Kind regards,

Christian