[FEATURE] Implemeting the new web-browser choice from RPIOS 12, which adds support for Mozilla Firefox

[DMW007]

Is your feature request related to a problem? Please describe.
The recently released Raspberry Pi OS 12 Bookworm introduced official support for the Mozilla Firefox web-browser, as described in this entry. Previously, only Chromium was supported.

It seems that when pre-configuring the Raspberry Pi OS 12 with Imager, it will keep both browsers, but sets chromium as default:

$ update-alternatives --config x-www-browser
There are 3 choices for the alternative x-www-browser (providing /usr/bin/x-www-browser).

  Selection    Path                       Priority   Status
------------------------------------------------------------
* 0            /usr/bin/chromium-browser   90        auto mode
  1            /usr/bin/chromium-browser   90        manual mode
  2            /usr/bin/dillo              30        manual mode
  3            /usr/bin/firefox            70        manual mode

Describe the solution you'd like
Having the same choice in Imager, as we have in the first run assistent:

1. Choosing the default browser (Firefox or Chromium)
2. Having a checkbox to uninstall the other browser not selected in step 1. If this is checked, the other browser is uninstalled. Otherwise, only the default browser is touched.

Examples:

• I choose Firefox and check to uninstall the other browser. So Firefox should be set as default and Chromium removed.
• I choose Firefox and don't check to uninstall the other browser. Firefox should be set as default, Chromium is still present.

Describe alternatives you've considered
It should be possible to set the default browser using update-alternatives --config x-www-browser and optionally uninstalling the unwanted one with apt by searching the corresponding packages:

$ dpkg -l | grep chromium
ii  chromium-browser                     116.0.5845.102-rpt1                 arm64        Chromium web browser, open-source version of Chrome
ii  chromium-browser-l10n                116.0.5845.102-rpt1                 all          chromium-browser language packages
ii  chromium-codecs-ffmpeg-extra         116.0.5845.102-rpt1                 arm64        Extra ffmpeg codecs for the Chromium Browser
ii  rpi-chromium-mods                    20230925                            arm64        Raspberry Pi-specific mods to Chromium

However, I see more value to have this in the Imager, so it can be pre-configurated. And the settings from the assistent would match those from Imager.

Additional context
This is the new step for choosing the web-browser in the Raspberry Pi OS installation assistent, shown when no pre-configuration settings are made by imager:

[tdewey-rpi]

Thanks for the detailed report, @DMW007. The consideration you've made to the alternatives is particularly appreciated, as it helps narrow the focus of the change suggestion much more rapidly.

I wholly agree that this would present a better user experience, and dovetails with a wider initiative I'm looking at around deeper image customisation (in particular, pre-seeding packages and configurations).

Fitting this into our current UI would be somewhat challenging. The most obvious path is to add yet another modal dialog as part of the flashing process, and expand our data model so we can tag images that support this style of configuration (it would be counterproductive, for example, to offer it for Raspberry Pi OS Lite).

As such, I'm inclined to suggest we roll this into a UI rework, as a stage inside a flashing wizard. I believe this would allow Imager to more clearly communicate the ordering dependencies involved, and gain a larger drawable area to display the options themselves with associated help texts.

Unfortunately, however, this work will take longer - as it has to dovetail with our other commitments.

Please let me know if you find anything in the above idea particularly objectionable.

[DMW007]

@tdewey-rpi Also thank you for your reply! But why do you think, that another modal dialog is required? Since V1.8, imager has grouped the customization settings into tabs. It's a German OS installations, so they're labeled general, services and options. This makes sense, since the list of settings has been grown and required scrolling up to Imager V1.7. I'd add another tab for desktop customizations there:

Since Imager V1.8 asks the user if he want to configure/delete/use/not use his pre-configuration settings before flashing, I think this is already well integrated and could be extended to further settings.

In the backend, I totally agree that you need a flag in each image which indicates if the image can handle the desktop customizations. So this tab will be disabled or not shown if it doesn't make sense (e.g. the lite RPIOS as you said) or it is not supported - maybe in distributions like Ubuntu, if it's not possible to customize them using cloudinit or what the Imager is currently using.

Compromise idea

Another idea, which could be a trade-off: Adding a tab for running custom bash/shell scripts. I'd guess that this can be introduced more easily. With this possibility, users could set the browser using update-alternatives --set $key $value, e.g. update-alternatives --set x-www-browser /usr/bin/firefox and optionally uninstall the other one with another line of apt-get remove $package.

It has also the advantage, that users are able to extend their customizations way beyond this scope. For example, automatically installing additional packages like vim or pre-configuring other tools. Currently, this requires either manual work or provisioning by third party tools like Ansible, after the Imager pre-configuration has finished. This would increase flexibility, as it would also allow other functions to be added that may not be so relevant to most people, so it would not make sense to add them to the UI.

[tdewey-rpi]

Interesting proposals, @DMW007.

Unfortunately, I'm reticent to implement both ahead of a future UI paradigm change.

Expanding the OS customisation dialog

This is certainly my most favourable of the two, but still carries some undue knowledge into Imager, in my opinion. While this is broadly correct for Raspberry Pi OS, I can't imagine offering the choice for the 'Lite' variants, or OSes that may mandate a given browser, is a good plan. Today, we lack the infrastructure to enable per-OS customisations - you either get the entire bank, or none at all. Resolving that requires both changes to this repo, and annotation from OS providers - and we're not yet in a position to request further changes from the OS providers (but we are addressing that).

A tab for custom shell scripts

I'm deeply uncomfortable with presenting this without some serious warnings. I could see a world where first-time users copy-paste scripts from unscrupulous websites that do all sorts of mischeif, including (but not limited to):

1. Installing a rootkit
2. Installing a bitcoin miner
3. Inserting arbitrary SSH keys
4. etc

None of which we would be able to detect reliably - essentially leaving first-time and novice users in the cold. As I've stated on other bugs, my bias is to favour the new & inexperienced user experience over the technically able, and I can't see a way to make this option friendly enough while retaining the power you've described. We could, however, explore adding this as a CLI option - but I've not thought through the threat model enough to commit to that.

I hope this provides some view into my reticence - it's not that the suggestions are bad, but we're not in a position to strongly consider either.

[maxnet]

It has also the advantage, that users are able to extend their customizations way beyond this scope. For example, automatically installing additional packages like vim or pre-configuring other tools.

Besides the question whether it is desirable to have this functionality, be aware that there are technical limitations to the firstrun.sh hackery used as well.
There is no network connectivity configured when that runs, so hard to download anything.

If you want functionality like this it makes more sense to use Ubuntu Server as OS, in which you can just toss a list of packages to be installed in cloud-init's user-data file on the FAT partition.

[tdewey-rpi]

Tagging for 2.0