682984 - Thunderbird behaves poorly if external handler in mimeTypes.rdf no longer exists. Uncaught exception contentAreaClick.js :: openLinkExternally :: line 188

Status: NEW

(Thunderbird :: OS Integration, defect)

Description

[Jason Duell]

Just lost an hour on this one...

To replicate:

1) Go into mimeTypes.rdf and edit path of http/https handler to incorrect path

2) Try to open http/https link in Thunderbird:  you get no visible error at all.  Looking at the error console shows 

Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]

The solution is to delete (or fix) mimeTypes.rdf.  This is not at all obvious, though--an "Application not found" dialog, (or just tossing user back into the "you must choose an application to open this link" dialog) would be much better.

By the way. when you check "use this in the future" box in the "Choose an application" dialog, a little message shows up saying you can change this later in the Thunderbird preferences.  AFAICT that's not true--there's no way to change the entries in mimeTypes.rdf via the Preferences or anything else in the GUI (correct me if I missed something).  In the absence of a GUI tool, it might be nice to at least mention in the dialog that you need to change mimeType.rdf.  Or even just remove the unhelpful current message.

Comment 1

[Ludovic Hirlimann [:Usul]]

Why did you ended up doing 1) in the first place (I'm trying to understand your sue case here) ?

Comment 2

[Jason Duell]

I did #1 to replicate the situation of having a program that handles a given MIME type no longer be on the system at that location.   For instance, a user could have set chrome to be their handler for a given MIME type, then decided to install Firefox and deleted chrome from their system.  If that happens tbird will simply fail forever with no message anytime you try to open that MIME type.

Comment 3

[Wayne Mery (:wsmwk)]

I see this exception in error console, so I'm probably experiencing this problem in windows 7. I don't understand 
a) why I'm just starting to see this (as of 2011-10-12) **
b) why it seems to be _intermittent_ - I'm seeing failure only about 80% of clicks

** I'll have to think about what else i might have been doing. I did have a couple clicks, prior to this problem, where the web link opened the page in my message preview pane.


options says http/firefox document is pointing to "Nightly", which is correct. But I have not examined mimeTypes.rdf

Comment 4

[Wayne Mery (:wsmwk)]

Jason, this is not a regression, correct?

Comment 5

[Jason Duell]

Wayne,

My experience was that I removed some software at the location that mimeTypes.rdf pointed to, so generally it should only be "new" to users if their applications is gone or in different location.

But that doesn't fit with your experience of this being intermittent--sounds like a different issue :(

Comment 6

[Jason Duell]

To be clear: for my issue, I don't think this was a regression.  For the intermittent behavior, it might be a new regression and a different bug.

Comment 8

[Matt]

I think we should be looking at providing a fall-back to the user as suggested here.  These issues are becoming increasingly common in the support forums, especially in the cases where software moves it's default location.  Say from program files(X86) to program files. As Firefox is currently doing, and all new 64bit versions of software will do under windows.

Good user interface design here would see the user lead down the path to correct the default application.  Not left with no feedback at all.