(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](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](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)[https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-mac]. 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?
Bug 1314074 Comment 34 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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](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](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](https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-mac). 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?