589176 - [Mac] Opening files no longer shows a default helper app or suggested apps

Status: RESOLVED INCOMPLETE

(Toolkit :: Downloads API, defect)

Description

[Jonathan Watt [:jwatt]]

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.

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: screenshot of 2009-06-23 build with helpful dropdown

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: screenshot of 2009-06-24 build with unhelpful "Choose" button

Comment 3

[Jonathan Watt [:jwatt]]

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.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Please give an example of a kind of resource that Mozilla can't handle, but which (normally at least) has a default app.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

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).

Comment 6

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 7

[Jonathan Watt [:jwatt]]

.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.

Comment 8

[Jonathan Watt [:jwatt]]

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

Comment 9

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Of course it's also worthwhile testing with a clean profile.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 12

[Jonathan Watt [:jwatt]]

I'll check all that. Can you try the Firefox.app builds I linked to in comment 7 and comment 8?

I'm on OS X 10.6 BTW, not 10.5.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 14

[Jonathan Watt [:jwatt]]

Sorry, where I've said '.app' above, I meant '.dmg'.

Comment 15

[Jonathan Watt [:jwatt]]

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.

Comment 16

[Jonathan Watt [:jwatt]]

(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

Comment 17

[Steven Michaud [:smichaud] (Retired)]

> 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.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> 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".

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This is too old to debug on today's Firefox, as bot hthe dialog and MacOS handling changed in non trivial ways.
It was also not reproduced by Stepven at the time, so I think we can call this incomplete.