Closed Bug 516362 Opened 15 years ago Closed 3 years ago

Improve Mac first-run experience: detect that we're running from disk image

Categories

(Toolkit :: Startup and Profile System, enhancement, P1)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
All
macOS
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox93 --- fixed

People

(Reporter: limi, Assigned: jwatt, NeedInfo)

References

(Depends on 4 open bugs,
URL
)

Details

(Whiteboard: [mozmill][mac:integration])

Attachments

(7 files, 6 obsolete files)

Google Picasa 3.5 "Copy to Applications"
(deleted), image/png
Details
WIP Mac Installer Patch (v1.1)
(deleted), patch
Details | Diff | Splinter Review
Bug 516362 p1. Add a localized helper to prompt the user for approval to install the app. r=mstange,zbraniecki
(deleted), text/x-phabricator-request
Details
Bug 516362 p2. Add a localized helper to notify the user if installation fails. r=mstange,zbraniecki
(deleted), text/x-phabricator-request
Details
Bug 516362 p3. Add API to install from .dmg and relaunch. r=mstange
(deleted), text/x-phabricator-request
Details
Bug 516362 p4. Enable detection of run-from-.dmg and prompt to install and relaunch. r=mstange
(deleted), text/x-phabricator-request
Details
data review
(deleted), text/plain
Details
The full rationale for this can be found at: http://limi.net/articles/improving-the-mac-installer-for-firefox/ …but in short: * People that don’t understand the standard installation process on Mac should be helped towards their goal. * Downloading Firefox and then forgetting about the download should be less common. * Maintain the standard installation model for the users that prefer the drag & drop install method. * Make it possible to set Firefox as your default browser during the install process. How do we fix these problems? By supplying a dedicated installer in the disk image, similar to the standard Mac OS X application installer. We can fix all of these by using some capabilities of the standard Mac package installer and disk image creation tools supplied by Apple. In particular, they have features where you can run an installer when a disk image is mounted, like Apple does with some of their own disk images. This, combined with the auto-mounting of disk images downloaded via Safari, gives us an installation flow that is likely to not lose people along the way. The final installation flow should look like this: 1. Start the Firefox download. 2. When the download is complete, the disk image will mount automatically (if they were using Safari), and the Firefox installer runs. 3. The install procedure continues similar to how it happens on Windows. 4. As the last step of the process, the installer lets you set Firefox as the default browser, and start the application immediately. We have seen users forget that they just installed Firefox if you don’t let them start it at the end of the process, and make that the default choice. Note that experienced Mac users should be able to cancel the installer at any time and drag the Firefox application to the location they want instead, thus there should be no loss of functionality or flexibility for them.
See Bug 289465 - need to investigate mpkg installer format for MacOS X systems.
My experience with mac installers (.pkg format) is that they have weird permissions problems unless you do a privileged install (prompts for passwords, installs as root)... and I'm afraid the privileged install will then not work with user updates. Do we know how to make an installer which installs as the user, without privileges, instead of in sudo mode?
fwiw I've actually met OS X users who ran Firefox out of the disk image, and would go to the effort of downloading Firefox over and over again, every time they rebooted their computer and it unmounted the disk image (which they referred to as "Apple deleting Firefox"). One of reasons our installation UI is a problem on OS X is that for a lot of people Firefox is the only third party app they install, so this is their first experience with the drag and drop process of adding applications to their computer.
It's been a while since I created a Mac OS X package, so I couldn't tell you off the top of my head how to do this, but you do have postinst scripts available (I believe apple's term is "post-flight"). If you really want the user to own the directory, do a script with a chown -R $User /Applications/Firefox.app at the end. Another option would be to distribute updates as their own packages: you can require that a certain version be installed (although you might need to check that in a preinst script) and distribute only the files that need to be replaced. Installer gets called each time and the user is authenticate.
Will there be a way of running a silent installation of Firefox without any action made by the user? I would love to see it because I need this feature for our software update tests with Mozmill.
You can do that today with the bundle... since the bundle is going to stay around, it seems like you could continue to do that without a problem, just skip the installer.
Installer packages are not a good experience for Mac users because they can't see what is being done to their system. This makes many users uncomfortable, as evidenced by tools like Pacifist and Suspicious Package. On related topics, requiring superuser access for software that doesn't have a legitimate need for it is certainly a very, very bad idea because it trains users to be careless with their administrator password. It is also against Apple's guidelines. How about this: if Firefox is opened directly from the installation disk image, display the following modal dialog: --------------------------- Would you like to install Firefox? (Quit) (Copy to Applications folder) --------------------------- - 'Quit' does what it says. - 'Copy…' does what it says and then relaunches from its proper place. This is the 'default' (glowing blue) button. - The two buttons (parenthesised phrases) are the only two options, and no further interaction with Firefox is possible until one of them is clicked. - Knowledgeable users will never see this dialog because they already know what to do. - It will no longer be necessary to have an alias to the Applications folder on the disk image. - This avoids all of the problems I mentioned above as well as those mentioned in the original rationale.
Installers are opaque, slow, and not at all cool. Just "Internet-enable" the disk image: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Containers/Containers.html#//apple_ref/doc/uid/10000145i-CH4-SW4 Firefox will be auto-copied to the Download folder, the disk image auto-moved to the Trash, and users only need to drag Firefox to the Apps folder. Even if they do not, the app will still work just fine. Users wanting to keep the disk image, can fetch it in the Trash. Advanced users can even disable the auto-extraction feature: http://www.macosxhints.com/article.php?story=20040210141030190 but that is not a preference with a public UI, so almost nobody knows about it. My only doubt is how to keep the Apps alias inside the disk image for users that prefer dragging it themselves, or for when the disk image is kept and re-opened a later time, and not having it auto-copied to the Download folder. Maybe getting rid of it and just use a background with a "drag it to the Apps folder" written message is the only option.
Oh, regarding "forgetting about the download should be less common.", that also does not need an installer: on first launch add a pop-up asking to add it to the Dock. Moving the app around (from Downloads folder to the Applications folder) does not break the Dock alias either.
(In reply to comment #8) > How about this: if Firefox is opened directly from the installation disk image, > display the following modal dialog: > > --------------------------- > Would you like to install Firefox? > > (Quit) (Copy to Applications folder) > --------------------------- We did consider this, and will most likely use a variation of this combined with "internet-enabling" (sic) the dmg. I didn't want to do this by itself, but if the unpack/trash variant that is "internet enabled" works the way I hope, that's a very clean solution. I'll have to do some research to make sure there are no pitfalls (and test on Snow Leopard vs. Leopard vs. Tiger), but it looks promising so far. Thanks!
The only thing you will want to forsee is that, the moment you automate stuff (extraction and deletion of the disk image) there are some (non-beginner) users that are not going to like it (like me, but I completely see you point) who prefer to do things on their own (but do not know a preference to disable the automation exists). Another thing to consider, if only for being aware of it, is that users with encrypted home folders (FileVault) will be copying and not moving Firefox when they drag it to the Applications folder (since the home folder is an encrypted volume different from where the Apps folder reside, and drag&dropping to another volume defaults to copying instead of moving).
Just did some testing using DMG Enabler on the existing Firefox disk image, seems to mostly do what we're looking for even on Snow Leopard (where some people suggested that they had changed it for security reasons). So that's at least 30% good news today. :)
We should make sure to not break our testing habits, or at least damage them too much. I myself end up just firing up Firefox from the mounted image every now and then, to test a dialog or two in some language I don't speak. I guess the download folder magic wouldn't break that. I wonder what it does if there is already a different Firefox.app there, though. Not sure how this affects our runtime test infrastructure.
For reference, here's the Firefox 3.5.3 DMG, internet-enabled (no other changes): http://people.mozilla.com/~tmielczarek/Firefox 3.5.3.dmg I had to download it with Safari to get the desired behavior. (Do we have to do something special to trigger this behavior from Firefox's download manager?) It's a little weird, in that you briefly see our DMG folder with the big Firefox icon and Applications symlink, but then it goes away and you wind up with a "Firefox" directory in your downloads folder containing the app bundle and the Applications symlink. I guess this is probably better for novice users than the existing behavior, though. The pkg-dmg script we use already has support for enabling this, so it'd be a trivial patch: http://mxr.mozilla.org/mozilla-central/source/build/package/mac_osx/pkg-dmg#176 Just add it right here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#163
I think you need to check what happens for alpha/beta releases as well - would they overwrite installs of official builds, as the app bundle name is the same? (windows installer explicitly avoids overwriting official builds).
(In reply to comment #14) > We should make sure to not break our testing habits, or at least damage them > too much. I myself end up just firing up Firefox from the mounted image every > now and then, to test a dialog or two in some language I don't speak. I guess > the download folder magic wouldn't break that. I wonder what it does if there > is already a different Firefox.app there, though. > > Not sure how this affects our runtime test infrastructure. We could always generate .zip/.tar.bz2 archives for our Mac builds similar to how we generate .zip and .exe archives on Windows.
(In reply to comment #17) > (In reply to comment #14) > > We should make sure to not break our testing habits, or at least damage them > > too much. I myself end up just firing up Firefox from the mounted image every > > now and then, to test a dialog or two in some language I don't speak. I guess > > the download folder magic wouldn't break that. I wonder what it does if there > > is already a different Firefox.app there, though. > > > > Not sure how this affects our runtime test infrastructure. > > We could always generate .zip/.tar.bz2 archives for our Mac builds similar to > how we generate .zip and .exe archives on Windows. Only if we *have* to, please. The only reason we generate them on Windows is because they're necessary to create MARs. By the sounds of it, we can probably use the DMGs still, given that it seems to require browser tweaks to work.
(In reply to comment #15) > I had to download it with Safari to get the desired behavior. Mmm… yep, I did not know that. Seems only to work in Safari. In Firefox, even if you choose to open it with the default DiskImageMounter.app, it will behave as a normal disk-image and not do the auto routine. Bummer. I cannot confirm this but I would say Apple changed the behaviour along the way. By googling, it seems that an internet-enabled disk image should do the auto routine no matter which agent opens it (Safari, some other browser, or the very user by double-clicking –if his browser was not set to auto open downloaded files). Disk Utility has even some preferences that refer to internet-enabled images (move to Trash; show extracted files), so it would seem the behaviour should be global. Still, as in 10.5.8 they only seem to trigger if downloaded with Safari (and having "Open downloaded safe files" on). Maybe someone can ask Apple what's the deal with this sort of disk images?
"2. When the download is complete, the disk image will mount automatically (if they were using Safari), and the Firefox installer runs." Auto-running the installer is unacceptable. Ditto for auto-running the app thereafter. That smells too much like viral behavior. It will get Firefox banned from EVERY one of my client's corp networks. Please DO NOT auto-run EVER. "4. As the last step of the process, the installer lets you set Firefox as the default browser" Yet-another interaction during installation will require more support time. The norm is for apps to ask the user upon first launch. Please stick with that. Don't confuse the user more by making Firefox act differently than all other apps. "If you really want the user to own the directory, do a script with a chown..." If you make the installing user own the app then they can damage it later. So much for your app's integrity. WRT the current DMG... It needs some basic work. 1. On systems with limited screens (short/narrow), it opens partially off the screen to the right. 2. The dark blue background makes the black text almost totally unreadable by visually impaired users. 3. The folder doesn't have a name. It used to say "Applications", but no longer. 4. The empty arrow, with no description. Taken togets, it says you want the user to magically understand that the app with a name that cannot be read should be "arrowed" (whatever that means) to a folder with no name. Please take a look at how others make their distribution dmgs. Dropbox (great) or Adium (good), for example. Those make it obvious what the user should do. Thx, - Dan.
(In reply to comment #20) > 3. The folder doesn't have a name. It used to say "Applications", but no > longer. This is intentional. It's because we can't know the localized name of the folder beforehand, and having it say "Applications" on a non-english system looks bad. See bug 320155.
Stumbling in here from :limi's blog post... (In reply to comment #8) > How about this: if Firefox is opened directly from the installation disk image, > display the following modal dialog: > > --------------------------- > Would you like to install Firefox? > > (Quit) (Copy to Applications folder) > --------------------------- For what it's worth, M3InstallController does this on OS X: http://www.mcubedsw.com/dev You can run the app from an image, but will ask if you'd like to actually install it. I'd much rather have something like this than use an installer. Might just be me, but whenever I run into an installer for an app on Mac, I expect that it's doing things I'd probably rather it wasn't doing.
(In reply to comment #8) > How about this: if Firefox is opened directly from the installation disk image, > display the following modal dialog: > > --------------------------- > Would you like to install Firefox? > > (Quit) (Copy to Applications folder) > --------------------------- Code just released that does just that: http://www.potionfactory.com/node/251 (i.e. moves a running Mac application to the /Applications directory) The app the text refers to conveniently has a "do not warn me again" for users that know what they are doing).
(In reply to comment #15) > I had to download it with Safari to get the desired behavior. Post-processing or not of Internet-enabled disk images seems to be affected by system preferences of the "mounting-agent", as set in plist "Preference List" files at "/System/Library/PrivateFrameworks/DiskImages.framework/Resources/agent-defaults/". In that folder, "dim.plist" is the one that affects DiskImageMounter.app, the default helper assigned by Launch Services, which is what is triggered when a user double-clicks, and, I guess, what Firefox uses to determine what program should auto-open a file. dim.plist has an explicit "skip-idme" boolean pref set to 1, which effectively means NOT to post-process internet-enabled images. There are preference files for a bunch of other "mounting-agents", but the only ones that seem not be explicitly set as such are "safari" and "osd", which I do not know what it stands for. It is without question that modifying anything inside /System/ is not recommended.
Interesting, but that ought to be a separate bug. This bug is about the Firefox installer, which most people are likely to be downloading with Safari.
(In reply to comment #25) > Interesting, but that ought to be a separate bug. I was not describing a bug. If you are going to be using an installing method that only works if downloaded with Safari, you'd better be aware of it, and why.
(In reply to comment #14) > We should make sure to not break our testing habits, or at least damage them > too much. I myself end up just firing up Firefox from the mounted image every > now and then, to test a dialog or two in some language I don't speak. I guess FYI, beyond casual testing like Axel described, I think it's pretty common regression-hunting behavior to download/open the dmg, run the app, test the regression, and quit, all without having to wait to copy the app off of the .dmg. When you're doing this 20+ times, all that copying gets really bothersome.
(In reply to comment #23) > The app the text refers to conveniently has a "do not warn me again" for users > that know what they are doing). In light of others' comments about testing, I guess a third, 'Continue Without Installing' button is needed. But I don't think a 'don't ask again' checkbox is a good idea. It's a small thing to ask testers to click an extra button on launch, and they will quickly develop the muscle memory to do it without even thinking about it. On the other hand, for users that don't understand what the dialog means, or don't bother to read it, seeing it every single time they launch Firefox is not only a subtle hint that they are doing something wrong, but a way to ensure they will always have a path towards fixing it.
(In reply to comment #28) > I guess a third, 'Continue Without Installing' button is needed. > > But I don't think a 'don't ask again' checkbox is a good idea. It's a small > thing to ask testers to click an extra button on launch, and they will quickly > develop the muscle memory to do it without even thinking about it. If I understood correctly, you suggest not letting users who do explicitly want to launch the app from the disk image to make the message go away forever with one additional click the first time they launch the app, and instead force them to click "Continue without installing" each time and every time they launch it? A small thing to ask in your opinion… incredibly irritating in mine. Clicking a button is indeed easier than clicking a checkbox. That is indeed the point: only people that read the thing and know what they are doing check the box. The rest do not even notice it is there, so they do not clic it by accident, they just go with the blue button. I think a third button provides more complexity to a non-advanced user, while making the life of people in the know more annoying. I do not see what good it provides to either. > On the other hand, for users that don't understand what the dialog means, or > don't bother to read it, seeing it every single time they launch Firefox is not > only a subtle hint that they are doing something wrong, but a way to ensure > they will always have a path towards fixing it. Precisely why one would want to make the option not to give a warning as small as possible.
I have written a new post about the recommended direction we should take: http://limi.net/articles/firefox-mac-installation-experience-revisited/
Summary: Improve Mac install experience by including installer and running it at mount time → Improve Mac install experience: Detect that we're running from disk image or Download folder
(In reply to comment #0) > The full rationale for this can be found at: > > http://limi.net/articles/improving-the-mac-installer-for-firefox/ We no longer recommend using an installer to achieve this. The post has been updated with a link to the new approach.
I noticed tonight that Piasa 3.5 has a system similar to that proposed by David Deller. A quick download of the app using Safari may be worth doing to see how it works.
The fact that we do not have an installer at the moment makes it hard for us to put in several startup optimizations for OSX. An installer would make it much easier for us to improve firstrun startup speed on <=10.6 and cold startup speed on 10.6(via bug 514083 10-20%).
I disagree that we need an installer for this. We can just as well compress the binaries in a Snow Leopard-only build and deliver them to users compressed. No installer needed and no need for a lengthy compression process during installation! A much finer user experience.
Compressed files do not copy over from a DMG in a compressed state, a script is required to compress the files after copy. Whether this is on first load, or through an installer is up for discussion. Can we please use bug 514083 for this conversation.
Assignee: nobody → joelr
The easiest way to compress ourselves would be to launch the ditto command-line tool to copy/move ourselves and compress at the same time. Problem is that we'll be modifying a running executable if we are already in /Applications. Maybe we need to pop up a dialog on first run, state that we are gonna optimize and minimize space, exit to run ditto and then restart Firefox when we are done. How is that?
A bunch of interesting comments from Apple engineers: http://groups.google.com/group/darwin-dev/browse_thread/thread/592004a281f6b760 I'm posting here rather than in bug 514083 since I think it has to do with the general process of installation. To summarize so far... 1) The user who installed Firefox may not be the user running it so the latter user may not have permission to modify (compress?) Firefox 2) User may install Firefox on a shared partition, to be used with both Leopard and Snow Leopard. Compressing Firefox will render it unusable for Leopard in this shared scenario. We'll need to make compression optional. 3) Modifying the code of a running app is dangerous, so compression will need to happen outside of Firefox. Our updater is a separate app so we can do it there, right? 4) We won't be able to use Keychain APIs since updating ourselves in-place will break code signing.
It believe it is possible to resolve issues 1 and 3 via an external app... if it makes sense to put in the updater I don't see a problem with that. For issue 1 I believe Authorization Services would be needed to deal with someone else installing the app though it obviously wouldn't work if the user didn't have the rights to do so. http://developer.apple.com/mac/library/documentation/Security/Reference/authorization_ref/Reference/reference.html
We can't codesign at the moment since our update process modifies the application with downloaded binary code, right? If so then codesigning is a moot point.
I'm not familiar with the Mac Keychain APIs or how this would be different than it is currently. We sign the exe's and dll's on Windows and when we patch these files the signature on the updated dll's and exe's is retained.
It appears from the Darwin-Dev thread that we can code-sign -and- deliver code-signed updates with an updated signature. I think this boils down to pre-compressing and signing our Snow Leopard builds and updates.
Be aware that releng only signs milestone builds (e.g. release, beta, and rc... don't think they sign alpha builds) due to the time / effort needed to do so.
As can be seen from the above-DUP'd bug, I'm trying to start work on this - and wondering how best to shim in to the launch process. It seems ideal to get in as soon as possible, but this raises concerns about keeping a responsive UI. We need to start a run loop to let AppKit handle UI updates for any presented dialogs, but this Cocoa/AppKit run loop may need to be cancelled so that XUL can set up its own later. /browser/app/nsBrowserApp.cpp just before calling XRE_main() seems like it may be a good place, but I'm definitely open to suggestion. Also, guidance on how to start up Cocoa only to shut it back down would be great, if anyone has it.
On second thought, that would be Firefox-specific. Should attempt to fix for all Moz apps, thus should likely go in toolkit/xre/nsAppRunner.cpp.
Shouldn't you be looking at the update application?
Assignee: joelr → mozilla
Nope - this is about what happens if the user tries to run from the disk image (e.g. runs the app without "installing" it to the Applications folder.)
Status: NEW → ASSIGNED
Christian, are you still working on this? Would love to see us ship this as the standard way to do things on the Mac for 4.0. :)
Christian, is any work being done on this, or should we move it to nobody, so others can pick it up? :)
Moving to nobody as the person it is currently assigned to is non-responsive. May have somebody working on this soon.
Assignee: mozilla → nobody
Assignee: nobody → sgreenlay
Hi Scott! Thanks for taking this on. Moving your questions from email into the bug, easier to track that way. Hope you don't mind. :) > I got an 'internet-enabled' dmg creating through 'make package'. However, > this is only useful if the user downloads in Safari and have "Open 'safe' > files after downloading" enabled. Otherwise it appears as a normal DMG. That's OK. If you turned off the auto-opening of disk images, we assume you're capable of opening it manually. > It also required me to remove the 'Applications' alias from the disk image. Also OK, as long as we ask to move to /Applications (or ~/Applications when we can't do the former) on launch. > In addition to that, I have also been looking into where to put and how to > create a dialog that lets the user move Firefox to Applications (if they > choose to). Can it just be native Cocoa code (similar to: > http://github.com/potionfactory/LetsMove/) I think Cocoa is fine. We're not going to use this on any other platform. > or should it be more like: > http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#1819 Not sure what this does, personally. :) > Also, should it be written so that the UI can be changed by a UX person > without going into the code? I believe we can get this right pretty quickly, so I wouldn't worry about it.
Attached patch WIP patch for Mac 'Installer' (obsolete) (deleted) — — Splinter Review
This is a work in progress. This patch makes the packaged dmg 'internet-enabled', as well as adding a dialog on start-up that gives the user the option to add to dock and copy to Applications. There are sections marked 'TODO' that I am currently working on, and adding to Dock currently causes a crash. Please note that this patch also contains the changes made in fix v1.2 from bug 531552.
Attached patch WIP patch for Mac 'Installer' (obsolete) (deleted) — — Splinter Review
Attachment #471375 - Attachment is obsolete: true
Attachment #472047 - Flags: review?(joshmoz)
A couple questions regarding the behaviour of the installer: 1) should we give the option of installing to ~/Applications, automatically choose it if available (as done with LetsMove), or just ignore it? 2) should we give the option to install to a location that the user previously marked as 'ok' to run out of? For example, if the user copies the application to the Desktop and says it is 'ok' to run from there, should we assume that the user wants to install future versions of the application to the same location? A demo of the last can be seen at: http://people.mozilla.com/~sgreenlay/firefox-4.0b6pre.en-US.mac64.dmg (try copying and running form the Desktop, choose 'Do not Install', then run again from the dmg)
>automatically choose it if available (as done with LetsMove) If the user is trying to run from the DMG, they probably don't really understand the meaning of the applications folder being a place, so I think it might make sense for us to make the application folder our default, so that most users can just click the "um yeah, whatever you just said" button. >2) should we give the option to install to a location that the user previously >marked as 'ok' to run out of? For confused users, that might just get more confusing, and for user's who know what is going on, I think they are going to want to say "no don't copy to applications" and then directly control where they place their app.
(In reply to comment #56) > >automatically choose it if available (as done with LetsMove) > > If the user is trying to run from the DMG, they probably don't really > understand the meaning of the applications folder being a place, so I think it > might make sense for us to make the application folder our default, so that > most users can just click the "um yeah, whatever you just said" button. Yeah, ~/Applications is unlikely to be very common, so the flow would be: 1. Tell the user that we recommend installing the app to a standard location 2. Move to /Applications if we can, if not: 3. Move to ~/Applications 4. Automatically add to the dock People that disagree with any of these defaults can easily correct them by moving the file manually, and by un-docking the icon. > >2) should we give the option to install to a location that the user previously > >marked as 'ok' to run out of? > > For confused users, that might just get more confusing, and for user's who know > what is going on, I think they are going to want to say "no don't copy to > applications" and then directly control where they place their app. Yeah, I'd just try to not be very smart here, keep it simple. (And I know I mentioned that Quicksilver had this behavior by default, but the more I think about it, the more I think we shouldn't care about it) Other things that we need to figure out if we can do: * Internet-enabled DMG doesn't seem to select the file in the finder when downloaded, which is suboptimal — we should probably switch to .zip for this reason. * Is the code to compress the binary on OS X 10.6 in the system-standard way sill intended to be part of this process? (helps startup time, but haven't tracked progress on this lately)
(In reply to comment #55) > A demo of the last can be seen at: > http://people.mozilla.com/~sgreenlay/firefox-4.0b6pre.en-US.mac64.dmg (try > copying and running form the Desktop, choose 'Do not Install', then run again > from the dmg) I have tested this dmg installer with our Mozmill tests and we fail because of the system level modal dialog. Please make sure that scripts, which can install the application, are not blocked by this dialog. Thanks.
We currently use bzip2 for the compression format for DMG files, see bug 405704. This gives a smaller download, and decreases bandwidth required by Mozilla, compared to a zip archive. Would a tar.bzip2 select the file in finder when downloaded?
> * Is the code to compress the binary on OS X 10.6 in the system-standard way > sill intended to be part of this process? (helps startup time, but haven't > tracked progress on this lately) Yes, should run ditto on executables after copying them. This should be a followup bug.
(In reply to comment #59) > We currently use bzip2 for the compression format for DMG files, see bug > 405704. This gives a smaller download, and decreases bandwidth required by > Mozilla, compared to a zip archive. > > Would a tar.bzip2 select the file in finder when downloaded? If we are talking the Safari auto-decompress, tar.bzip2 will leave a .tar in the downloads folder (not the final .app)
As for HFS+ compression, ditto would compress the files. However, if any file is changed within the app bundle, from a user changing something or using the updater, the compression is lost. Perhaps this should be included in a 'first launch' script, which we would need for the updater and periodic checking to see if it is compressed. See bug 514083 and bug 534246. It's a 20% win in cold ts.
Whiteboard: [mozmill]
(In reply to comment #58) > I have tested this dmg installer with our Mozmill tests and we fail because of > the system level modal dialog. Please make sure that scripts, which can install > the application, are not blocked by this dialog. Thanks. If you want to skip the installer dialog (using the current dmg), just enter "write org.mozilla.minefielddebug NSIgnoreInstaller "YES"" in Terminal.
(In reply to comment #63) > If you want to skip the installer dialog (using the current dmg), just enter > "write org.mozilla.minefielddebug NSIgnoreInstaller "YES"" in Terminal. I tried but it failed with "usage: write user [tty]". Sadly the write command hasn't any man page or help option. I'm on 10.6.
That should probably be "defaults write org.mozilla.minefielddebug NSIgnoreInstaller "YES"" above.
(In reply to comment #65) > That should probably be "defaults write org.mozilla.minefielddebug > NSIgnoreInstaller "YES"" above. That did the trick. Reading this pref gives me the impression that the last part of the preference string is the name of the application in lower case? We do not know the name of the application before we have mounted the image. Would it be enough to set the preference at this point without getting the installer?
> Reading this pref gives me the impression that the last part of the > preference string is the name of the application in lower case? We > do not know the name of the application before we have mounted > the image. That identifier is set as part of the application at compile time; also be aware of org.mozilla.firefox for release builds. Also will apply in other apps built from the same tree, I'd guess - I have not yet looked at the code, but it should be general-purpose. > Would it be enough to set the preference at this point without > getting the installer? You can set it at any time. If the file "~/Library/Preferences/org.mozilla.minefielddebug.plist" does not exist the OS will create it for you. - - - - - Slight critique on the choice of preference key: since we're playing in the OS-level namespace here, is the "NS" prefix really the best idea? Apple may start using it at any time for an unrelated setting.
> Slight critique on the choice of preference key: since we're playing in the > OS-level namespace here, is the "NS" prefix really the best idea? Apple may > start using it at any time for an unrelated setting. I was following the same naming scheme as existing preferences: /toolkit/xre/MacApplicationDelegate.mm:100 [[NSUserDefaults standardUserDefaults] setObject:@"NO" forKey:@"NSTreatUnknownArgumentsAsOpen"];
(In reply to comment #67) > > Would it be enough to set the preference at this point without > > getting the installer? > > You can set it at any time. If the file > "~/Library/Preferences/org.mozilla.minefielddebug.plist" does not exist the OS > will create it for you. For the Mozmill tests you can expect a system where no other Firefox builds have been run so far. Having the DMG file we cannot see which name the application has. So we don't know about which file has to be created / modified under ~/Library/Preferences. That's why it would be important for us to know if the following steps will work: 1. Mount the DMG file 2. Run the default write command 3. Copy the application to the users temporary folder 4. Unmount the DMG file 5. Run Firefox/Minefield/Namoroka
(In reply to comment #69) > (In reply to comment #67) > > > Would it be enough to set the preference at this point without > > > getting the installer? > > > > You can set it at any time. If the file > > "~/Library/Preferences/org.mozilla.minefielddebug.plist" does not exist the OS > > will create it for you. > > For the Mozmill tests you can expect a system where no other Firefox builds > have been run so far. and of course, it equally applies for other non-Firefox applications...
Comment on attachment 472047 [details] [diff] [review] WIP patch for Mac 'Installer' > -framework QuickTime \ > -framework IOKit \ >+ -framework Security \ Indentation is off here. >+ * The Initial Developer of the Original Code is >+ * Mozilla Corporation. >+ * Portions created by the Initial Developer are Copyright (C) 2006 2006 -> 2010 >+ * Contributor(s): Add your name/email here so that people know who originally wrote this? Useful if someone wants to contact the author. >+ * Portions created by the Initial Developer are Copyright (C) 2006 >+ * the Initial Developer. All Rights Reserved. >+ * >+ * Contributor(s): Same comments about this second license block. >+int >+DisplayErrorMessage(NSString *title, NSString *text, NSString *iconPath) >+{ >+ Get rid of this blank opening newline. >+ SInt32 error = 0; Declare this further down where it is actually used. >+ CFURLRef iconURL = CFURLCreateWithString(kCFAllocatorDefault, >+ (CFStringRef)iconPath, >+ NULL); Prefix Mac OS X framework calls with "::", so "::CFURLCreateWithString". Makes it easier to determine what calls are to the frameworks and which are to our own functions. Don't need to do this for generic posix calls. This will need to be done at least a few times in this patch. >+ CFOptionFlags response = 0; >+ Get rid of the blank line here. >+ if (CFUserNotificationReceiveResponse(notification, 0, &response) == 0) { >+ switch (response & 0x3) { What is this 0x3? Rather not have a raw unexplained hex number here. >+ case kCFUserNotificationDefaultResponse: >+ >+ CFRelease(notification); >+ CFRelease(properties); >+ CFRelease(iconURL); >+ >+ return 1; Get rid of the blank lines in this code. Remember to prefix CFRelease with "::". >+ default: >+ // TODO: ERROR: Invalid response to notification Get rid of the TODO, I don't think we plan to do anything abou >+ break; >+ } >+ } >+ >+ CFRelease(notification); >+ CFRelease(properties); >+ CFRelease(iconURL); Why do this release stuff twice? I think you can just get rid of the whole switch statement above and just record the return value you want for returning at the end. >+BOOL >+isInDock(NSString *path) >+{ >+ NSUserDefaults * defaults = [NSUserDefaults standardUserDefaults]; >+ [defaults addSuiteNamed:@"com.apple.Dock"]; >+ >+ for (NSDictionary *dictionary in [defaults objectForKey:@"persistent-apps"]) { >+ NSString *app = [[[dictionary objectForKey:@"tile-data"] objectForKey:@"file-data"] objectForKey:@"_CFURLString"]; >+ if ([app isEqualToString:path]) { >+ return YES; >+ } >+ } >+ >+ return NO; >+} This stuff is not properly indented. Two spaces, not tabs. We haven't used the "in" syntax for loops in our code before, either don't use it or make sure it compiles on the earliest compiler we support (whichever 10.5 xcode install has the first release-quality version of gcc-4.2). Easier just to not use it. More comments to come.
Attachment #472047 - Flags: review?(joshmoz) → review-
Attached patch WIP Mac Installer Patch (v1.1) (deleted) — — Splinter Review
Some known things that need to be changed: - different localization method (the standard XUL system is not initialized when this code is used) - move installer.properties somewhere else
Attachment #472047 - Attachment is obsolete: true
Attachment #478824 - Flags: review?(joshmoz)
Whiteboard: [mozmill] → [mozmill][target-betaN]
Assignee: sgreenlay → joshmoz
Are we planning to pick this up again for FF5/6?
We have no plans at the moment, AFAIK. I won't be able to work on this soon.
Assignee: joshmoz → nobody
Whiteboard: [mozmill][target-betaN] → [mozmill]
Comment on attachment 478824 [details] [diff] [review] WIP Mac Installer Patch (v1.1) I don't think this patch will apply any more and it needs some more work (I think localization is a big remaining issue). Canceling review. We'll need to find a new owner for this.
Attachment #478824 - Flags: review?(joshmoz)
Hardware: x86 → All
Version: 3.6 Branch → Trunk
Just had the holiday-software-update-for-family experience. Uncle was running Firefox from the dmg.... for years. Had four different Firefox versions mounted (and Skype and some Flash updates). He'd dragged the binary in the dmg to the dock, would run it from there. I figured it out because he complained that he'd try to run the updater, and the progress meter would spin forever, with no other user feedback. So bad.
Status: ASSIGNED → NEW
Priority: -- → P3
Type: defect → enhancement
Whiteboard: [mozmill] → [mozmill][mac:integration]

Taking a fresh look at this.

Assignee: nobody → spohl.mozilla.bugs
Severity: normal → S2
Status: NEW → ASSIGNED
Priority: P3 → P1
Assignee: spohl.mozilla.bugs → jwatt

Hi Michelle. As you requested (via mbalfanz) here's some proposed wording for the popup that will be presented to the user. How does this seem to you, and what is the process for improving the text and getting it signed off?

Do you want to install Firefox?

You're currently running Firefox from its disk image. Running
from its disk image will prevent Firefox saving your browsing
session and settings, and will prevent Firefox from staying
up to date and secure.

                         | Don't install |    | Install |
Flags: needinfo?(mheubusch)

(In reply to Jonathan Watt [:jwatt] from comment #79)

Hi Michelle. As you requested (via mbalfanz) here's some proposed wording for the popup that will be presented to the user. How does this seem to you, and what is the process for improving the text and getting it signed off?

Do you want to install Firefox?

You're currently running Firefox from its disk image. Running
from its disk image will prevent Firefox saving your browsing
session and settings, and will prevent Firefox from staying
up to date and secure.

                         | Don't install |    | Install |

Hi Jonathan - I drafted a few versions of copy and Meridel Walkington is reviewing now. I will route past Martin after that and post final copy here.

Flags: needinfo?(mheubusch)

Hi Michelle, I didn't here back from you here but the last text I got via Martin was this:

Finish installing Firefox?

Complete this one-step installation to help keep Firefox up to
date and prevent data loss. Firefox will be added to your
Applications folder and Dock.

                                   [Don’t Install]   [Install]

Thumbs up on getting rid of the technical wording!

Just FYI that's the text we're going with unless you say otherwise.

Flags: needinfo?(mheubusch)
Component: Installer → Startup and Profile System
Product: Firefox → Toolkit
Summary: Improve Mac install experience: Detect that we're running from disk image or Download folder → Improve Mac first-run experience: detect that we're running from disk image
Version: Trunk → unspecified
Attachment #9235983 - Attachment description: Bug 516362 p1. Implement a localized prompt asking for approval to install to /Applications. r=mstange → Bug 516362 p1. Implement a localized prompt asking for approval to install to /Applications. r=mstange,zbraniecki

Depends on D122685

Attached file Bug 516362. Debugging - not to land. r=mstange (obsolete) (deleted) —

Depends on D122687

Attachment #9236378 - Attachment is obsolete: true
Attachment #9235983 - Attachment description: Bug 516362 p1. Implement a localized prompt asking for approval to install to /Applications. r=mstange,zbraniecki → Bug 516362 p1. Add a localized helper to prompt the user for approval to install the app. r=mstange,zbraniecki
Attached file data review (deleted) —

Not currently actually requesting review in case whoever picks up adding the telemetry while I'm on PTO wants to tweak the text it contains.

Depends on: 1726833
Attachment #9236383 - Attachment is obsolete: true
Attachment #9236380 - Attachment description: Bug 516362 p3. Add a localized helper to notify the user if installation fails. r=mstange,zbraniecki → Bug 516362 p2. Add a localized helper to notify the user if installation fails. r=mstange,zbraniecki
Attachment #9236381 - Attachment description: Bug 516362 p4. Add API to install from .dmg and relaunch. r=mstange → Bug 516362 p3. Add API to install from .dmg and relaunch. r=mstange
Attachment #9236382 - Attachment description: Bug 516362 p5. Enable detection of run-from-.dmg and prompt to install and relaunch. r=mstange → Bug 516362 p4. Enable detection of run-from-.dmg and prompt to install and relaunch. r=mstange
Attachment #9236379 - Attachment is obsolete: true

Comment on attachment 9238411 [details]
Bug 516362 p5. Add ability for standard users to install from a DMG through elevation. r=mstange

Revision D123899 was moved to bug 1728167. Setting attachment 9238411 [details] to obsolete.

Attachment #9238411 - Attachment is obsolete: true
Pushed by spohl@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1e2f80bda8b4 p1. Add a localized helper to prompt the user for approval to install the app. r=zbraniecki,fluent-reviewers,flod https://hg.mozilla.org/integration/autoland/rev/723ec69bb57e p2. Add a localized helper to notify the user if installation fails. r=mstange,zbraniecki https://hg.mozilla.org/integration/autoland/rev/eb8885d5cd62 p3. Add API to install from .dmg and relaunch. r=mstange,spohl https://hg.mozilla.org/integration/autoland/rev/12f1b1fee451 p4. Enable detection of run-from-.dmg and prompt to install and relaunch. r=mstange

Backed out 4 changesets (Bug 516362) for causing mochitest bc failures on browser_all_files_referenced.js.
Backout link
Push with failures
Failure Log

Flags: needinfo?(jwatt)
Pushed by spohl@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/976a6e8b9933 p1. Add a localized helper to prompt the user for approval to install the app. r=zbraniecki,fluent-reviewers,flod https://hg.mozilla.org/integration/autoland/rev/3aec1c9de239 p2. Add a localized helper to notify the user if installation fails. r=mstange,zbraniecki https://hg.mozilla.org/integration/autoland/rev/e154fb92d731 p3. Add API to install from .dmg and relaunch. r=mstange,spohl https://hg.mozilla.org/integration/autoland/rev/a207d21b3eca p4. Enable detection of run-from-.dmg and prompt to install and relaunch. r=mstange
Blocks: 1728339

This was working in local builds but it does not appear to be working in Nightly now that the patches are landed. I'm investigating in bug 1728339.

No longer blocks: 1728339
Depends on: 1728339

(In reply to Markus Stange [:mstange] from comment #96)

This was working in local builds but it does not appear to be working in Nightly now that the patches are landed. I'm investigating in bug 1728339.

That bug is now fixed and things work as expected in the latest Nightly. See bug 1728530 comment 2 for some caveats.

No longer depends on: 1729306

Is that something that should be mentioned in release notes?

(In reply to Pascal Chevrel:pascalc from comment #98)

Is that something that should be mentioned in release notes?

We could do, but I don't think so. This change is expected to be hit by a minority of new users who are also new to mac and don't know how to install a .app correctly. I guess it might also be hit by some advanced users who are deliberately running from mounted .dmg but presumably those are most likely to be internal Firefox testers?

Flags: needinfo?(jwatt)
Regressed by: 1730287
No longer regressed by: 1730287
Regressions: 1730287

(In reply to Jonathan Watt [:jwatt] from comment #99)

(In reply to Pascal Chevrel:pascalc from comment #98)

Is that something that should be mentioned in release notes?

We could do, but I don't...

After speaking with other members of the team, we decided that we should add some mention of this change to the release notes. Can we add the following text?

To prevent session loss for inexperienced macOS users, Firefox now requests the user’s permission to install itself if it is being run from a mounted .dmg file. This request is only made the first time Firefox is run on a user’s computer.

Flags: needinfo?(pascalc)

(In reply to Jonathan Watt [:jwatt] from comment #100)

(In reply to Jonathan Watt [:jwatt] from comment #99)

(In reply to Pascal Chevrel:pascalc from comment #98)

Is that something that should be mentioned in release notes?

We could do, but I don't...

After speaking with other members of the team, we decided that we should add some mention of this change to the release notes. Can we add the following text?

To prevent session loss for inexperienced macOS users, Firefox now requests the user’s permission to install itself if it is being run from a mounted .dmg file. This request is only made the first time Firefox is run on a user’s computer.

Note added to our beta relnotes, thanks.

Flags: needinfo?(pascalc)
Depends on: 1709598
Blocks: 1743328
Blocks: 1729837
No longer depends on: 1729837
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: