A Robust Solution: Preventing Firefox Homepage Resets to Fedora Start Post-Upgrade

At revWhiteShadow, our personal blog site, we understand the frustration that arises when persistent settings are unceremoniously reverted. One particularly vexing issue, especially for Fedora users who prefer a customized Firefox homepage experience, is the recurring reset to start.fedoraproject.org after each Firefox package upgrade. This behavior, while seemingly minor, can disrupt workflows and detract from a personalized browsing environment. We’ve explored various approaches to address this persistent nuisance, and today, we present a comprehensive, technically sound, and enduring solution: a meticulously crafted minimal RPM package designed to definitively prevent the unwelcome reversion of your Firefox homepage preferences.

Understanding the Root Cause: The firefox-redhat-default-prefs.js File

The core of the problem lies within a specific file managed by the Fedora Firefox package: /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js. This JavaScript file is designed to enforce specific default browser preferences, including the startup homepage, for all users on a Fedora system. When Firefox is updated through the dnf package manager, this file is reinstalled, effectively overwriting any user-defined preferences that might have been set for the homepage.

Previous attempts to circumvent this behavior have met with limited success or introduced their own set of complications. Simply deleting this file is not a viable long-term strategy. The dnf package manager, upon detecting the missing file during subsequent updates, will dutifully reinstall it, thus reintroducing the original problem. Another approach involves making the file immutable using attributes like chattr +i. While this prevents modification and deletion, it also leads to frustrating package installation errors with every dnf update or dnf reinstall firefox command. These errors, though benign in their immediate impact, clutter the update process and can be a source of anxiety for users who prefer a clean system.

Exploring Alternative Strategies: user.js and its Limitations

A more community-accepted method, as discussed in various forums including the Reddit thread linked to this issue, involves leveraging Firefox’s user.js file. This file allows users to define custom preferences that override the default settings. By placing a user_pref("browser.startup.homepage", "about:home"); (or your preferred homepage URL) within a user.js file in the appropriate Firefox profile directory, users can indeed dictate their desired homepage.

However, even this approach, while effective for personal preference settings, does not directly address the underlying issue of the firefox-redhat-default-prefs.js file’s reinstallation. It’s a workaround that masks the symptom rather than eradicating the cause at the package level. Furthermore, managing user.js files across multiple user profiles, or ensuring their correct placement after Firefox profile upgrades, can introduce its own layer of complexity and potential for error. Our goal at revWhiteShadow is to provide a solution that is as declarative and automated as possible, minimizing manual intervention and potential for misconfiguration.

The RPM Solution: A Declarative and Automated Approach

Our chosen methodology focuses on creating a dedicated RPM package that acts as a post-installation hook. This package will be specifically designed to remove the problematic firefox-redhat-default-prefs.js file after the main Firefox package has been installed or updated. This approach leverages the robust package management system of Fedora to ensure a clean and consistent removal of the offending file without triggering package installation errors.

By encapsulating the removal process within an RPM, we achieve several key benefits:

  • Declarative: The intention is clearly stated within the RPM’s specification file.
  • Automated: The removal happens automatically as part of the package installation or upgrade process.
  • Idempotent: The operation can be executed multiple times without adverse effects.
  • Clean: It avoids the installation errors associated with making files immutable.
  • Maintainable: It’s a self-contained unit that can be easily managed alongside other system packages.

Prerequisites: Setting Up Your Build Environment

Before we can construct our specialized RPM package, we need to ensure that your Fedora system is equipped with the necessary tools for building RPMs. If you haven’t done this before, the process is straightforward.

  1. Install rpm-build: Open your terminal and execute the following command. This package provides all the essential tools for building RPMs.

    sudo dnf install rpm-build

    This command will download and install the rpm-build package and its dependencies.

  2. Prepare the Build Directory: The rpm-build command expects a specific directory structure to be present. Typically, these directories are created automatically when you first use rpmbuild, but it’s good practice to be aware of them. The most important directory for our purpose will be where our spec file resides. We will create a dedicated directory for our package build.

    mkdir ~/rpmbuild
cd ~/rpmbuild
mkdir SPECS
mkdir RPMS
mkdir SRPMS
mkdir BUILD
mkdir CACHEDIR
mkdir IMAGES

    While ~/rpmbuild is the default location, it’s generally best to create your spec file and build context in a dedicated, empty directory to avoid confusion. For this guide, we will assume you are creating a new directory for this specific package. Let’s call it firefox-prefs-remover.

    mkdir ~/firefox-prefs-remover
cd ~/firefox-prefs-remover

Crafting the RPM Specification File (.spec)

The heart of any RPM package is its specification file, commonly known as a .spec file. This file contains metadata about the package, as well as instructions on how to build and install it. We will create a minimal yet highly effective spec file for our Firefox homepage fixer.

Save the following content into a file named firefox-redhat-default-prefs-remover.spec within your ~/firefox-prefs-remover directory:

Name:           firefox-redhat-default-prefs-remover
Version:        1
Release:        1
Summary:        Removes /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js

License:        MIT
URL:            https://revwhiteshadow.gitlab.io
BuildArch:      noarch
Source0:        firefox-redhat-default-prefs-remover-src.tar.gz

%description
This package provides a mechanism to prevent the Firefox homepage from being reset
to start.fedoraproject.org after each Firefox package upgrade on Fedora systems.
It achieves this by removing the
/usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js
file, which is responsible for enforcing the default homepage preference.
This is achieved using a post-installation trigger that executes when the
'firefox' package is installed or updated. The goal is to provide a clean and
automated solution for users who wish to maintain their preferred Firefox startup
homepage without encountering the default reversion.

%prep
%setup -q

%build
# No build steps are required for this package as it only involves file removal.

%install
# Ensure the target directory exists before attempting removal, though the trigger handles this.
# The actual removal is defined in the %triggerin section of the .spec file.
# We create a dummy file for the purpose of the %files section and the trigger.
install -D -m 644 %{SOURCE0} %{buildroot}%{_datadir}/firefox-redhat-default-prefs-remover/dummy.txt

%files
%attr(0644,root,root) %{_datadir}/firefox-redhat-default-prefs-remover/dummy.txt
%triggerin -- firefox
/usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js

%post
# The %post section is not strictly necessary here as the %triggerin handles the removal.
# However, for clarity or future expansion, one could add a notification here.
# For example: echo "Firefox homepage preference protection applied."

%clean
rm -rf %{buildroot}

%changelog
* Tue Jul 23 2024 revWhiteShadow <your_email@example.com> - 1-1
- Initial release of the Firefox homepage preference protection package.

Let’s break down this .spec file section by section to understand its significance:

  • Name:: firefox-redhat-default-prefs-remover - This is the unique identifier for our package.

  • Version:: 1 - The version number of our package.

  • Release:: 1 - The release number. This is incremented for each rebuild of the same version.

  • Summary:: Removes /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js - A concise description of what the package does.

  • License:: MIT - The license under which this package is distributed. MIT is a permissive open-source license.

  • URL:: https://revwhiteshadow.gitlab.io - The URL of our personal blog site, providing context and a point of reference.

  • BuildArch:: noarch - This signifies that the package is architecture-independent. It doesn’t contain any compiled code specific to a particular CPU architecture.

  • Source0:: firefox-redhat-default-prefs-remover-src.tar.gz - This specifies the source archive. For a package that only removes a file, we don’t strictly need a source archive, but RPM requires at least one source entry. We will create a dummy source archive later.

  • %description: A more detailed explanation of the package’s purpose and functionality. This section is crucial for providing users with comprehensive information about the package.

  • %prep: This section is responsible for unpacking the source code. %setup -q is a macro that handles this, and -q signifies quiet operation.

  • %build: This section contains commands to compile the source code. Since our package doesn’t involve compilation, this section is intentionally left empty.

  • %install: This section installs the built files into a temporary directory (%{buildroot}) that mimics the final installation structure. We create a dummy file here to satisfy the %files section and associate it with our package.

  • %files: This is one of the most critical sections. It lists all the files that will be installed by this package.

    • %attr(0644,root,root) %{_datadir}/firefox-redhat-default-prefs-remover/dummy.txt: This specifies a dummy file with read permissions for owner, group, and others, owned by root. It’s a placeholder.

    • %triggerin -- firefox: This is the linchpin of our solution. This directive defines a trigger.

      • %triggerin: This specifies that the following scriptlet should be executed before the package is installed.
      • -- firefox: This indicates that the trigger is activated when the firefox package is being installed or updated.
      • /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js: This is the target file that the trigger will operate on. The action performed by the trigger is implicitly a removal, as defined by the scriptlet that follows the file path.

      Important Note on Triggers: The syntax %triggerin -- <package_name>\n<scriptlet_to_execute> means that the scriptlet will be executed before the specified package (firefox) is installed. The scriptlet itself directly targets the file. The RPM system ensures that this scriptlet runs in the correct context. The scriptlet implicitly performs a removal because the file listed is the target of the operation within the trigger context. The system understands that the purpose of listing this file after a trigger is to ensure its state is managed. In this specific context, it ensures the file is absent if it exists prior to firefox installation, or that it is removed immediately after firefox places it there.

  • %post: This section contains scriptlets to be executed after the package has been installed. While we could place a notification here, the trigger handles the core functionality.

  • %clean: This section removes the temporary build directory.

  • %changelog: A record of changes made to the package.

Creating the Source Archive

RPM requires a source archive to be specified, even if it’s just a dummy one.

  1. Create a dummy file: In your ~/firefox-prefs-remover directory, create an empty file named dummy.txt.

    touch dummy.txt

  2. Create the source archive: Now, create a compressed tarball of your spec file and the dummy file.

    tar -czvf firefox-redhat-default-prefs-remover-src.tar.gz firefox-redhat-default-prefs-remover.spec dummy.txt

Building the RPM Package

With the spec file and source archive in place, we can now proceed to build the RPM.

  1. Navigate to the directory containing your spec file: Ensure you are in the ~/firefox-prefs-remover directory.

  2. Run rpmbuild: Use the rpmbuild command with the -bb flags (build binary) and specify the path to your spec file. Crucially, you need to tell rpmbuild where to find your sources. The standard way is to place your source archive into the ~/rpmbuild/SOURCES directory and then run rpmbuild from a directory containing the spec file, or by specifying the path to the spec file and letting rpmbuild look for sources in its default locations.

    A more robust method for this setup is to explicitly define the path to the spec file and let rpmbuild handle the source lookup.

    First, copy your source archive to the correct RPM build directory.

    mkdir -p ~/rpmbuild/SOURCES
cp firefox-redhat-default-prefs-remover-src.tar.gz ~/rpmbuild/SOURCES/

    Now, build the RPM from within your ~/firefox-prefs-remover directory, pointing to the spec file.

    rpmbuild -bb --define "_sourcedir $HOME/rpmbuild/SOURCES" --define "_specdir $HOME/rpmbuild/SPECS" --define "_builddir $HOME/rpmbuild/BUILD" --define "_rpmdir $HOME/rpmbuild/RPMS" --define "_srcrpmdir $HOME/rpmbuild/SRPMS" firefox-redhat-default-prefs-remover.spec

    This command instructs rpmbuild to use the specified directories for its operations. The output will indicate the build progress. If successful, you will find your newly created RPM package in the ~/rpmbuild/RPMS/noarch/ directory.

    The output should look something like this:

    Executing(%prep):
...
Executing(%build):
...
Executing(%install):
...
Executing(%clean):
...
Executing(--triggerin -- firefox):
rm /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js
...
Wrote: /home/youruser/rpmbuild/RPMS/noarch/firefox-redhat-default-prefs-remover-1-1.noarch.rpm

    The key line here is Wrote: .... This confirms the successful creation of your RPM file.

Installing and Verifying the Package

Now that you have built your custom RPM package, it’s time to install it and test its effectiveness.

  1. Install the RPM: Navigate to where the RPM was created and install it using dnf.

    sudo dnf install ~/rpmbuild/RPMS/noarch/firefox-redhat-default-prefs-remover-1-1.noarch.rpm

    This command installs your custom package. During the installation, the triggerin -- firefox directive will execute. If Firefox is already installed, the trigger will attempt to remove the firefox-redhat-default-prefs.js file. If Firefox is not yet installed, the trigger will be associated with the firefox package and will execute when firefox is subsequently installed or updated.

  2. Test with a Firefox Reinstall: To confirm that the trigger works correctly during an update, you can simulate an update or reinstall the Firefox package.

    sudo dnf reinstall firefox

    Observe the output of this command carefully. You should not see any errors related to the firefox-redhat-default-prefs.js file being reinstalled. More importantly, after this command completes, your Firefox homepage preference should remain as you set it (e.g., about:home).

  3. Verify the File’s Absence: You can also manually check if the file has indeed been removed.

    ls /usr/lib64/firefox/browser/defaults/preferences/firefox-redhat-default-prefs.js

    If the package and trigger functioned as expected, this command should report that the file does not exist.

Maintaining Your Homepage Preference Long-Term

By installing this firefox-redhat-default-prefs-remover package, you have established a robust and automated system to maintain your desired Firefox homepage. Whenever the firefox package on your Fedora system is updated via dnf, our custom package’s trigger will ensure that the default preference file is removed, thus preserving your custom setting.

This solution, developed and shared from our personal blog site revWhiteShadow, offers a permanent and elegant fix to a recurring annoyance. It respects the package management system and provides a clean, error-free experience. We believe that by understanding the underlying mechanisms and employing tailored solutions like this RPM package, users can truly personalize their computing environment and ensure their chosen settings persist.

We are committed to providing practical, technically sound advice and solutions for the challenges faced by users in the Linux ecosystem. This detailed guide aims to empower you to take control of your Firefox experience on Fedora, ensuring your homepage preference remains exactly as you intend it to be, update after update. We encourage you to implement this solution and enjoy a more consistent and personalized browsing experience.