Cross-linking Bug 1601148 and its related SUMO threads for reference, such as this one. The TL;DR is that the "running from a randomized location" behaviour means that users who Join Firefox by signing in with their Firefox Account, will be signed out every time they restart the browser, because their profile directory gets recreated in a new location.

Put another way: this bug means we're losing potential Firefox Accounts MAU :-)

I don't have a good sense from the scrollback of how actionable this bug is. Is it something that a member of the FxA or Sync client teams could potentially take on with a bit of mentoring? Is there a way we could gather telemetry about how often this happens in practice?

ni? :mossop as the triage owner, but please redirect me as appropriate, I'm well into unfamiliar territory in this part of Firefox.

(In reply to Ryan Kelly [:rfkelly] from comment #23)

Cross-linking Bug 1601148 and its related SUMO threads for reference, such as this one. The TL;DR is that the "running from a randomized location" behaviour means that users who Join Firefox by signing in with their Firefox Account, will be signed out every time they restart the browser, because their profile directory gets recreated in a new location.

Put another way: this bug means we're losing potential Firefox Accounts MAU :-)

I don't have a good sense from the scrollback of how actionable this bug is. Is it something that a member of the FxA or Sync client teams could potentially take on with a bit of mentoring? Is there a way we could gather telemetry about how often this happens in practice?

There are two chief problems here:

1. Detecting that we're in this state. I haven't spotted any API for this. Potentially we could rely on the apparent install location structure, it seems to be similar each use but that may change as OSX is updated and in different locales.
2. Figuring out what to actually do when in this state. There are two or three things that could cause it and I suspect that we cannot solve any of them in Firefox code. A new binary that gets elevated permissions could probably solve some of them but otherwise it will be up to the user to manually fix it.

I think bug 1557401 is the real problem here which is kinda fallout from bug 1474285, which hasn't really had much work done since it was released.

I think that profile per install based on directory location is not a great design to begin with; it should be keyed to something intrinsic to the Firefox binary, not the install or launch location.

Thanks for the context! I don't disagree with anything in Bug 1557401, but I do think that "Firefox forgot all my settings for no obvious reason" is a different and worse user experience than "Firefox forgot all my settings after I deliberately moved the application". I'd be happy with a fix that addressed the first issue without addressing the second, if it meant the fix was more tractable. But...

Detecting that we're in this state. I haven't spotted any API for this.

From this, and my own poking around on the web, "tractable" doesn't seem like the right word here, at least not yet.

(In reply to Ryan Kelly [:rfkelly] from comment #23)

Is there a way we could gather telemetry about how often this happens in practice?

So we do send a telemetry event when a new profile is created in startup. If there was some way to correlate the pings for a single user then seeing a high number of those events could be a signal. But since it is a new profile each time we won't have a client ID so we'd have to correlate against machine data, which hopefully is difficult.

(In reply to Ryan Kelly [:rfkelly] from comment #26)

Thanks for the context! I don't disagree with anything in Bug 1557401, but I do think that "Firefox forgot all my settings for no obvious reason" is a different and worse user experience than "Firefox forgot all my settings after I deliberately moved the application".

It is the same thing -- from bug 1557401:

A user may think "well, let me try out Firefox", downloads the app, runs it (doesn't "install"), enjoys the experience, and before they unmount the disk image, they move the application to /Applications or similar (like ~/Applications).

What happens after that is that the user "loses" data, and is immediately turned off to Firefox, thinking that it can't retain its own preferences, and promptly switches back to their previous browser.

They may also have an extremely bad taste in their mouth and tell their friends and colleagues that Firefox loses data and is unreliable, and ought not to be used.

It is literally the same issue, except with the added step of them actually deciding that they like Firefox enough to move it outside of a disk image or downloads folder (perhaps even signing up for Fxa).

(In reply to Asif Youssuff from comment #28)

It is literally the same issue, except with the added step of them actually deciding that they like Firefox enough to move it outside of a disk image or downloads folder (perhaps even signing up for Fxa).

The two have the same effect in terms of creating a new profile, in bug 1557401's case because the install location has changed and in this case because the install location has appeared to change. However in bug 1557401's case the user only gets a new profile when they move the bundle while here the user gets a new profile every time they restart Firefox with no action on the user's part.

The solution to the two is also likely to be different. Fixing bug 1557401 would not solve this bug entirely because translocation causes other problems beyond the profile issue.

(In reply to Asif Youssuff from comment #28)

A user may think "well, let me try out Firefox", downloads the app, runs it (doesn't "install"), enjoys the experience, and before they unmount the disk image, they move the application to /Applications or similar (like ~/Applications).

Fixing this bug could solve that scenario.

Another live example here: https://www.reddit.com/r/firefox/comments/eodn3j/logs_me_out_everytime/

Every time I close and sleep my computer firefox signs me out. It is working fine on my pc but on my Mac, it signs me out every time. I have already tried going to history and unchecking cookies and everything but it still does it. Any help would be great thanks!

This definitely needs to be addressed ASAP, since the issue was worsened with the new profile management updates in Firefox 67. Here are some samples of users who have issues with this:

• https://support.mozilla.org/en-US/questions/1277757
• https://support.mozilla.org/en-US/questions/1274546
• https://support.mozilla.org/en-US/questions/1274114
• https://support.mozilla.org/en-US/questions/1272397
• https://support.mozilla.org/en-US/questions/1277314
• https://support.mozilla.org/en-US/questions/1277759 (Potentially)

This continues to be an issue in the real world. See https://www.reddit.com/r/firefox/comments/mh6d79/keeps_crashing_losing_login_info/ for example:

I recently got a new Macbook Air and so Firefox has crashed 3 separate times - each time losing the saved logins for every single site and acts like it's been installed for the very first time.

The user eventually confirms that Firefox is being run from the disk image and has not moved it to a stable location on disk. Unfortunately, this causes issues due to bug 1557401.

Taking a fresh look at this.

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

There are two chief problems here:

1. Detecting that we're in this state. I haven't spotted any API for this. Potentially we could rely on the apparent install location structure, it seems to be similar each use but that may change as OSX is updated and in different locales.

Going off the directory structure should be a good first start and we can probably iterate on this as we move forward.

2. Figuring out what to actually do when in this state. There are two or three things that could cause it and I suspect that we cannot solve any of them in Firefox code. A new binary that gets elevated permissions could probably solve some of them but otherwise it will be up to the user to manually fix it.

As a first step I've been debating between a doorhanger and an about: page in the style of about:restartrequired.

1. Doorhanger: The advantage of a doorhanger is that it allows a user to try Firefox without having to drag it to disk. However, it is easy to dismiss. This may not be a particularly big issue because the doorhanger would display every time Firefox is started from the DMG.

2. about: page: A page similar to about:restartrequired would force users to install Firefox properly before using it, which has the potential to lead to a better retention rate and MAU.

As a start, both of these options could simply direct to our macOS installation help page.

An elevated binary to "fix" this issue for an end user does not seem to be the right approach. If we were to invest in an elevated helper to address this issue, we should first revisit whether or not we want to develop an installer for macOS. Just like the about: page, an installer would prevent users from trying Firefox before it is installed properly. Previously, we have always leaned against adding an installer because it is "not the macOS way". There has arguably been an influx of Windows users to the macOS platform. It is typical for Windows applications to be installed with an installer, hence an increased number of bug reports surrounding a lack of installer on macOS and/or confusion around how to properly install Firefox from a DMG.

I believe as a first step we should decide how aggressive we want to be about notifying a user that they are running from an unsupported location and choose between a doorhanger (less aggressive) or an about: page (more aggressive).

Mossop, what are your thoughts?

(In reply to Stephen A Pohl [:spohl] from comment #34)

(In reply to Dave Townsend [:mossop] from comment #24)
I believe as a first step we should decide how aggressive we want to be about notifying a user that they are running from an unsupported location and choose between a doorhanger (less aggressive) or an about: page (more aggressive).

Mossop, what are your thoughts?

I think since this causes you to lose all your data between each run we should probably be pretty aggressive. I'm not totally sure whether completely blocking browsing is right or not, I'd be interested to hear Romain's take here.

Anecdotal but I see more and more macOS apps come as .app installers these days.

I thought it might help the conversation to have screenshots of what these two options might look like. I agree that a more aggressive approach might be preferred here.

Comment on attachment 9214785 [details]
Doorhanger option

I think this looks more visually aggressive than that about: page actually. If there were a way to make this persistent (open in every window, on every tab and no close button) then that might serve the right purpose. Constant reminder you are using Firefox in a way that causes problems but still able to try some things out if needed.

Handing this over to Jonathan who has been looking into this as well.

(In reply to Stephen A Pohl [:spohl] from comment #34)

An elevated binary to "fix" this issue for an end user does not seem to be the right approach. If we were to invest in an elevated helper to address this issue, we should first revisit whether or not we want to develop an installer for macOS. Just like the about: page, an installer would prevent users from trying Firefox before it is installed properly. Previously, we have always leaned against adding an installer because it is "not the macOS way". There has arguably been an influx of Windows users to the macOS platform. It is typical for Windows applications to be installed with an installer, hence an increased number of bug reports surrounding a lack of installer on macOS and/or confusion around how to properly install Firefox from a DMG.

Reminder that we do already build an installer[1]. We should consider making the installer the default download.

1. https://ftp.mozilla.org/pub/firefox/releases/86.0.1/mac/en-US/Firefox%2086.0.1.pkg

(In reply to Haik Aftandilian [:haik] from comment #41)

Reminder that we do already build an installer[1]. We should consider making the installer the default download.

1. https://ftp.mozilla.org/pub/firefox/releases/86.0.1/mac/en-US/Firefox%2086.0.1.pkg

This has been considered at various times before and we have always continued to favor a dmg over the pkg for regular installs as far as I'm aware. The pkg installer was created for enterprise deployments. I don't believe that there has been a change in perspective on this but I'm going to see if someone has up-to-date info. It's been a while since I've dealt with this.

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

(In reply to Stephen A Pohl [:spohl] from comment #34)

(In reply to Dave Townsend [:mossop] from comment #24)
I believe as a first step we should decide how aggressive we want to be about notifying a user that they are running from an unsupported location and choose between a doorhanger (less aggressive) or an about: page (more aggressive).

Mossop, what are your thoughts?

I think since this causes you to lose all your data between each run we should probably be pretty aggressive. I'm not totally sure whether completely blocking browsing is right or not, I'd be interested to hear Romain's take here.

Anecdotal but I see more and more macOS apps come as .app installers these days.

Passing over to Martin who'll be focussing on this space soon

We are exploring multiple solutions to work on in Q2.

I agree that we need to be fairly aggressive here. The goal needs to be to catch users before they run into problems. One approach that I like is what Chrome is doing: When starting Chrome from the dmg, they will show a prompt offering the user to install. Hitting "Install" will then copy Chrome to the /Applicatons folder and start it from there. "Don't Install" will run it from the dmg. I see us doing something along the similar lines.

This could be combined will with other helpful methods, e.g. as spohl presented above. I could also imagine to add instructional text to the dmg background. As users indicated on SUMO, the arrow is not self-explanatory.

Exploration is happening right now, so please keep the comments coming :)

I think a dialog to move the app to /Applications will probably help most users, except those who are not administrators of the machine. I don't have the data to know how large of a userbase that might be, but I would assume that means that we would still need to try to find a stable location to store the app as a secondary candidate in that case. Otherwise, we continue to run the risk of running into bug 1557401 on subsequent launches after a user has moved the binary to a temporary location to escape the suggestions in comment 34, and has proceeded to move the application to a "stable" location.

Offering to move to /Applications sounds like a good first step though, assuming that many users are also administrators.

We implemented the prompt to install Firefox in bug 516362 and have telemetry to monitor the effect on users. Once that data starts to come in in January we'll consider whether the ideas in comment 34 here or some other fixes/approach are necessary, but we'll open new more targeted bugs for that. (And there's still bug 1601148 open, of course.)