Open Bug 1752975 Opened 2 years ago Updated 1 year ago

Support portable installations of Firefox

Categories

(Firefox :: Installer, enhancement, P3)

Product:
Firefox
Component:
Installer
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: Tom25519, Unassigned)

References

Details

(Whiteboard: [fidedi-ope])

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

Steps to reproduce:

I tried to storage Firefox in my flash disk so that I can use it in any computer.

Actual results:

But seems Firefox only nightly or candidate version has zip package version.

Expected results:

Add zip package for Firefox release version in ftp.mozilla.org for portable usage and/or add decompress option in Firefox installer.

By the way, I feel portable version Firefox shouldn't change the registry or anything out of the folder, except for bookmarks or downloaded files.

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

Component: Untriaged → Installer

I feel portable apps (*.paf.exe files) is also a good implement because it's easy to update with keeping user data.

Component: Installer → Untriaged
Component: Untriaged → Installer

bhearsum: I thought we did publish ZIP files of releases, but archive.m.o doesn't have them. Do you know where to look?

Flags: needinfo?(bhearsum)

(In reply to Nick Alexander :nalexander [he/him] from comment #4)

bhearsum: I thought we did publish ZIP files of releases, but archive.m.o doesn't have them. Do you know where to look?

We have never in the modern era officially released supported zip builds (this appears to date back to https://bugzilla.mozilla.org/show_bug.cgi?id=287499#c12). We do have zips available in directories such as https://archive.mozilla.org/pub/firefox/candidates/97.0b9-candidates/build1/win64/en-US/, but that's more of a historical technical artifact than anything else.

In any case, candidates dirs like the above have zips, but you can also run 7z x on an installer to end up with the same thing (plus a few extract nsis artifacts).

Flags: needinfo?(bhearsum)

So, I think that it is quite unlikely that we are going distribute more zip packages than we already do. If anything, it is probably more likely that we would stop distributing the zip packages that we do now. We essentially addressed this in Bug 287499 Comment 12, and I think that that reasoning basically still stands.

However, it sounds to me like, at its core, this request is essentially for a more portable version/installation/mode of Firefox. This, I think that we should seriously consider. I'm not sure exactly how we would want it to work, but here are some things that we would need to consider:

  • What would the installation process look like? Would we add an option in our existing installer? Or maybe this ought to have a separate installer?
  • I'm not familiar with the *.paf.exe format suggested in Comment 3. Maybe we should look into that.
  • What would update look like? Presumably we would be able to self-update without any elevation, which we already support doing. But the current location of the update directory isn't great for portable usage. Ideally, we would instead want it to live somewhere on the USB drive with the installation.
  • We would want to move the profile directory to somewhere on the USB drive.
  • I'm not sure what things we change that aren't in the profile directory, but we would probably need to look into it. Most or all of these would need to be disabled in "portable mode". No files come to mind, but there is definitely some registry access that we would have to take a look at.
  • Are there security implications of running Firefox this way? We should run this by the security team.
  • Certain features should probably be disabled in portable mode. Off the top of my head: "set to default browser" functionality, the WDBA, Background Update, probably Background Tasks in general, BITS.
  • Are there any OS-specific considerations that I'm not thinking of? A truly portable (cross-OS) version sounds super cool, but I'm not sure how reasonable that is.

We might want to change the installation structure slightly, in order for there to be a more clear place for things like the profile and update directories. For example, something like:

Firefox/
        Firefox (launcher)
        Installation/
        Profiles/
        Update/

I'm not sure exactly what that launcher should be. Some kind of link to the binary, maybe? Or a binary launcher that simply invokes the actual binary? Or maybe it could be the actual binary, somehow configured to be able to find the rest of its files in the installation directory?

A structure like this would make it possible to keep a bunch of associated data around without just putting it directly in the installation directory. We could opt not to do this and put everything directly inside, but (a) it would be annoying to find the binary amongst all the other files, and (b) we would have to teach the updater to ignore certain parts of the installation. Another potential option would be to put these other directories somewhere else entirely (ex: D:\firefox_data\), but that feels unappealing. It's quite likely that Firefox will share the USB drive with other documents, data, and software and we don't want Firefox's data to get removed when the user is, say, attempting to free up some space.

I should note that, currently, there isn't anything really stopping someone from running our regular installer and specifying a directory in a USB drive as the install location. But I don't think that that would do a great job of making it truly portable. The issues above are all examples of things that wouldn't work quite right in this configuration. Probably the most serious of those issues is the non-portable location of the profile directory, which would mean that the user would lose all their data (history, bookmarks, etc) every time they switched systems.

Priority: -- → P3
Summary: Add zip package for Firefox release version in ftp.mozilla.org for portable usage and/or add decompress option in Firefox installer → Support portable installations of Firefox
Whiteboard: [fidedi-ope]
QA Whiteboard: QA-not-actionable

Hi!
For Tor Browser we have had a patch to make it portable for many years, and recently I have reworked it.

As Robin wrote in previous comments, distributing Firefox in an archive is not enough, because it will keep using the profile in the computer where Firefox is being used (both the local and root profile directories).
So, we modify toolkit/xre/nsXREDirProvider.cpp to look for the profiles in a directory relative to the firefox binary directory.
We also modify xpcom/io/nsAppFileLocationProvider.cpp, which has a similar function, to be on the safe side, but if I understand correctly, it is never used for Firefox.
In addition to that, we disable any feature that would write to the Windows registry, such as the various services, the default browser agent and the system policies.

We would love to upstream our patches, at least partially.
Would Mozilla be interested in having them in the Firefox codebase? This Bug is for the Installer component. So, in case, should I open a new one for the patch in the right component?

Thanks in advance.

(In reply to Pier Angelo Vendrame from comment #7)

So, we modify toolkit/xre/nsXREDirProvider.cpp to look for the profiles in a directory relative to the firefox binary directory.
We also modify xpcom/io/nsAppFileLocationProvider.cpp, which has a similar function, to be on the safe side, but if I understand correctly, it is never used for Firefox.
In addition to that, we disable any feature that would write to the Windows registry, such as the various services, the default browser agent and the system policies.

How do you decide when to do this? Do you do it unconditionally?

For the profile directory we have a pair of checks:

  • on macOS:
    • we test whether the binary path starts with /Applications/: if it does, we disable portable mode
    • we check if we can create the profile directory: if we cannot, we disable portable mode: we do this to handle the "running from the DMG" case
  • on other platforms we recently added a check for a system-install file adjacent to firefox/firefox.exe, and disable the portable mode if it exists.

We favor portable mode because we want to avoid disk leaks. But in the patch we will upstream we can change this behavior, if needed, and then change it back on Tor Browser with another patch.

For the other changes (the ones not to use the registry, the default browser agent and system policies), we do it always, because we can do it only at compile time (and we are not interested in them anyway).

Hmm. I'm not sure whether we want to use those heuristics for determining this if we ought to be in portable mode. The one used on macOS seems like a broader net then what I think we want to cast here. And I'm not sure what the system-install file is about. My Firefox installation does not seem to have one, and I can't find a reference to that in the codebase. Is that a Tor-specific thing?

(In reply to Robin Steuber (they/them) [:bytesized] from comment #10)

And I'm not sure what the system-install file is about. My Firefox installation does not seem to have one, and I can't find a reference to that in the codebase. Is that a Tor-specific thing?

Yes, it is.

What you say makes sense, and it's the reason for which I am asking if you could be interested in a similar patch, but with other heuristics.
Maybe for the Firefox use-case it could make sense to make an additional build to be used only in portable mode.
I haven't checked yet, but an idea I just had is that maybe it could be possible to build only an additional firefox.exe (e.g., firefox.portable.exe), without building XUL and the other libraries again. Then the zip archive could contain firefox.portable.exe instead of firefox.exe.

(In reply to Pier Angelo Vendrame from comment #11)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #10)

And I'm not sure what the system-install file is about. My Firefox installation does not seem to have one, and I can't find a reference to that in the codebase. Is that a Tor-specific thing?

Yes, it is.

What you say makes sense, and it's the reason for which I am asking if you could be interested in a similar patch, but with other heuristics.
Maybe for the Firefox use-case it could make sense to make an additional build to be used only in portable mode.
I haven't checked yet, but an idea I just had is that maybe it could be possible to build only an additional firefox.exe (e.g., firefox.portable.exe), without building XUL and the other libraries again. Then the zip archive could contain firefox.portable.exe instead of firefox.exe.

(With apologies for the fly-by....)

Another way to achieve this might be to use a heuristic to enable it, with "off" being the default. For example, inverting what you described a few comments back, and only turning it in when a specific file is present.

Yeah, on Windows, I think this would be best implemented by a setting in the installer. But adding a setting to the installer would be a bit annoying on the full installer, and prohibitively difficult on the stub installer.

On macOS, we might be able to add this to the pkg installer. I'm not sure if there is any way to add it to the dmg installer.

Unfortunately, I don't have time to work on these installer changes at the moment.

I noted above

What would update look like? Presumably we would be able to self-update without any elevation, which we already support doing. But the current location of the update directory isn't great for portable usage. Ideally, we would instead want it to live somewhere on the USB drive with the installation.

I still think that this solution is the preferred option. But if we don't go down the route of moving the update directory, we should remember that there are some other files that we write to the update directory that we should consider putting somewhere else or removing:

  • profile_count_(HASH).json
  • uninstall_ping_(HASH)_(UUID).json
  • UpdateLock-(HASH)
You need to log in before you can comment on or make changes to this bug.