63.74 KB, image/png
61.51 KB, image/png
On Mac, when you click on a link to a resource that Mozilla doesn't handle natively, it will prompt you with a dialog window to either choose a helper app to open it with, or to save the file. The user experience with this dialog window has regressed quite a bit. The regression seems to have occurred between 2009-06-23-03-mozilla-central and 2009-06-24-03-mozilla-central. In this regression the "Open with" line stopped providing a drop down menu with a default app shown and selected, and instead replaced the drop down with a "Choose" button. This change gives a much poorer user experience because, whereas before users typically just had to: * click the "Open with" radio button * click "OK" (seeing the default app was acceptable) they now typically have to * click the "Open with" radio button * click the "Choose" button * decide which app to use - in my case I often don't even know the name of the _default_ app, which is really frustrating when it should just have been suggested to me! * scroll to the helper app and select it * click the "OK" button * click the next "OK" button These extra tedious and often frustrating steps make the new user experience really suck. Especially so if you're opening multiple files in quick succession! If you try to skip the "Choose" button and just select "Open with" and click "OK", you get a popup error message saying: The application you chose ("") could not be found. Check the file name or choose another application.
Attachment #467772 - Attachment description: screenshot of 2009-06-24 build with helpful dropdown → screenshot of 2009-06-23 build with helpful dropdown
The hg revisions for the builds are: 2009-06-23-03-mozilla-central: 28aa23105a9e 2009-06-24-03-mozilla-central: 5fe89f2c22f0 Unfortunately given how painful it is to try and figure out the config and env issues to get old code building, I've not been able to get builds to narrow down that range. However, it looks like the commit for bug 489864 was the only commit to touch uriloader/exthandler, so it looks highly suspect.
Please give an example of a kind of resource that Mozilla can't handle, but which (normally at least) has a default app.
Or to put the question another way, please give examples of resources which are handled correctly on the 1.9.2 and 1.9.1 branches (which don't have the patch for bug 489864) but not on the trunk/1.9.3 branch (which does have the patch).
Now I see that you've already provided one example in your screenshots -- *.dmg files. And I've found another on my own -- *.pdf files. But I don't see any difference in behavior with either of these resources between a recent trunk nightly and FF 3.6.8. I tested on a plain-vanilla OS X 10.5.8 system. Later I'll test on OS X 10.6.4. With *.dmg files, both the trunk nightly and FF 3.6.8 give you the Choose button. But with *.pdf files, both builds default to opening with Preview.
.app file: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/2009-06-23-03-mozilla-central/firefox-3.6a1pre.en-US.mac.dmg .zip file: http://qtdemo-plugin.googlecode.com/files/QtDemoPlugin-win-1.3.0-with-opengl.zip Or any other file types that require a helper app I'm guessing. That .app link is actually the link to the last build that works nicely, so if you install that and try the two links out in it you'll see the nice old behavior.
And for convenience here's a link to the next day's build where things broke: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/2009-06-24-03-mozilla-central/firefox-3.6a1pre.en-US.mac.dmg
You might want to try rebuilding your Launch Services database (http://hints.macworld.com/article.php?story=20031215144430486). On OS X 10.5 and 10.6 the command is: /System/Library/Frameworks/CoreServices.framework/\ Frameworks/LaunchServices.framework/Support/lsregister \ -kill -r -domain local -domain system -domain user Thanks for the info about *.app and *.zip "files" (*.app bundles are of course directory trees). Do you also get the desired behavior (on the trunk and the 1.9.2 branch) with *.pdf files?
Of course it's also worthwhile testing with a clean profile.
I also get the "correct" behavior with *.zip files (on OS X 10.5.8) in both my recent Minefield nightly and FF 3.6.8 -- the dialog lists Archive Utility as the default application.
By the way, my tests so far have all been opening local files. I get the same ("bad") results following links to *.dmg files (e.g. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/2009-06-24-03-mozilla-central/firefox-3.6a1pre.en-US.mac.dmg), and the same ("good") results following links to *.pdf files (e.g. http://developer.apple.com/legacy/mac/library/documentation/Carbon/Reference/Carbon_Event_Manager_Ref/Carbon_Event_Manager_Ref.pdf). But I get "bad" results following your link to http://qtdemo-plugin.googlecode.com/files/QtDemoPlugin-win-1.3.0-with-opengl.zip, even though I get "good" results opening local *.zip files. In all cases Minefield and FF 3.6.8 behave the same way. I've still only tested on OS X 10.5.8. Of course a web site might provide the "wrong" MIME information about one of its files ... but that's probably unusual.
Sorry, where I've said '.app' above, I meant '.dmg'.
And to rebuild the Launch Services database on 10.6 is a little different: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user It makes no difference to the behavior though.
(In reply to comment #5) > Or to put the question another way, please give examples of resources which are > handled correctly on the 1.9.2 and 1.9.1 branches (which don't have the patch > for bug 489864) Actually the 1.9.2 branch *does* have the patch for bug 489864: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2816cca3be16
> Actually the 1.9.2 branch *does* have the patch for bug 489864: Argh! You're right. I spaced out looking at the tinderbox push log. I'll need to retest with 1.9.1 branch builds. By the way, I also tested with the 2009-06-23-03-mozilla-central and 2009-06-24-03-mozilla-central builds, and my experience with them matches yours exactly. Everything works "correctly" in the first build. But in the second build, though *.pdf files are always handled "correctly", *.zip and *.dmg files are always handled "incorrectly". Something has since happened to change the behavior (on the trunk and 1.9.2 branch) with *.zip files -- so there's something more going on here than just the patch for bug 489864. Also, it's entirely possible the new behavior may turn out to be one or more Apple bugs, about which we might not be able to do anything.
> I'll need to retest with 1.9.1 branch builds. I've now tested with FF 3.5.11 on OS X 10.5.8. Like the 2009-06-23-03-mozilla-central build, it behaves entirely "correctly".
Summary: Opening files with a helper app on Mac has regressed → [Mac] Opening files no longer shows a default helper app or suggested apps
You need to log in before you can comment on or make changes to this bug.