Closed Bug 392403 Opened 13 years ago Closed 12 years ago

Latest Thunderbird trunk doesn't use default browser for urls

Categories

(Core Graveyard :: File Handling, defect, P5, major)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: waynegwoods, Assigned: dmose)

Details

(Keywords: regression, Whiteboard: [proto])

Can't find a dupe for this, unless it's under a summary with an obscure component name in the title ;)

1. With latest Thunderbird nightly, open a message that contains a url.
2. Click on the link.
3. Instead of opening it in your default web browser, it brings up a "Launch Application" dialog box (badly styled and lacking all browser options except Firefox), which wants you to select a browser. Error console gives an error that reads:
  uncaught exception: load of <url> denied.

For fear of permanently stopping Tbird using the default app, I haven't selected a new browser in the Launch Application box. I did try setting a different default browser (FIrefox instead of Minefield) but it didn't help.

This regressed between the 20070812-05 and 20070813-04 nightlies. If you go back to 20070812, it still works.

Not sure what caused it... bug 391640 maybe?
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 391980
This has the same root trigger as bug 391980, but I don't think it necessarily has the same resolution.  In particular, there are not any plans to have the new dialog expose the "system default" choice to the UI in the Firefox 3 timeframe.  A big piece of the problem is that the external helper app code has a lot of front-end and back-end logic entrained together.  There will be some cleanup in the Firefox 3 timeframe, but it's not clear whether there will be a sufficient amount of help out here.  One option would be to populate Thunderbirds RDF with "system default" stuff for common URI protocols.  It's also possible that there may be a way to fix this as part of bug 391980; that's not yet clear.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Thanks for the explanation Dan! I'll set a blocking request just to be safe. There's no way the product could be released without this fix, the bug is already making it awkward to use the latest nightlies on a regular basis. Cheers.
Flags: blocking-thunderbird3?
On my system (Vista), the only app in the list is IE, even though I have Minefield as the default browser.
This really is a File Handling bug...
Status: REOPENED → NEW
Component: General → File Handling
Flags: blocking-thunderbird3?
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: general → file-handling
Hardware: PC → All
Target Milestone: --- → mozilla1.9 M9
This is a problem for all toolkit based apps that aren't browsers. We really shouldn't ship 1.9 without a fix.
Flags: blocking1.9?
Whiteboard: [proto]
Flags: blocking1.9? → blocking1.9+
Currently, this is listed as blocking beta as it is targeted for M9 and listed as blocking.  As I see it, I don't think this should block the beta.  Thoughts?
As we're not shipping a Thunderbird beta at this time, I agree.
Moving this to the next milestone.  Thanks, Ted.
Target Milestone: mozilla1.9 M9 → mozilla1.9 M10
Priority: -- → P5
Target Milestone: mozilla1.9 M10 → mozilla1.9 M11
Assignee: nobody → dmose
I've come to believe that the right fix for this is to simply add http and https to the whitelist using the warn-external preferences.
(In reply to comment #10)
> I've come to believe that the right fix for this is to simply add http and
> https to the whitelist using the warn-external preferences.
> 

These prefs have been there for a long time (they were added in 2004 in the version 1.7 of all-thunderbird.js).

Anyway, the bug appears to be fixed.  I can reproduce it with the 2007-12-03-03 nightly but not with the 2007-12-04-03 nightly. (I tested on Mac OS 10.5)

In this range, the best candidate to have fixed this is the patch from bug 397906.
So I don't know if this bug is FIXED, WFM or DUP of 397906.
I tend to agree with your suspicion that this got corrected as a side effect of the fix for bug 397906.
Status: NEW → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → FIXED
Er, I can still reproduce with the latest trunk nightly of Thunderbird. This never went away for me. What did you use to test? And are you sure you didn't check the "Remember" box in the dialog window, which I guess would hide the problem?
(In reply to comment #13)
> Er, I can still reproduce with the latest trunk nightly of Thunderbird. This
> never went away for me. What did you use to test?

1. Download the nightly, extract, launch
2. Click on "Unsent" in "Local Folders", the "Welcome to Mozilla Thunderbird!" page appears in the message area.
3. Click on the "Thunderbird Product Page" link (or any other http link).

> And are you sure you didn't
> check the "Remember" box in the dialog window, which I guess would hide the
> problem?
> 

Yes I'm sure. I have just checked again, with the 2007-12-03-03 nightly, the window appears as described in comment 0, the "Remember" checkbox is unchecked. With the latest nightly, Firefox goes to the foreground with an additional tab opened, displaying the Thunderbird product page.
Strange. Not for me. If I click on the "Thunderbird Product Page" link, or any other link, it still brings up the dialog box. I wonder what's different...
Thunderbird uses the system default browser without asking only if you never selected any other browser. I guess if you once clicked on Firefox in the dialog and clicked ok, Firefox was added to the list of applications for http. And as the list of non-system default application is not empty, you still get the dialog.

Deleting the file mimeTypes.rdf in your profile folder should make the dialog disappear.
(In reply to comment #16)
> Deleting the file mimeTypes.rdf in your profile folder should make the dialog
> disappear.

That did it, thanks :)
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.