If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

If no default browser is set, we try to open external urls like attachments

RESOLVED FIXED in Thunderbird1.1

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
14 years ago
6 years ago

People

(Reporter: Scott MacGregor, Assigned: Scott MacGregor)

Tracking

unspecified
Thunderbird1.1
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

14 years ago
Sometimes there is no default browser set on a user's machine or the registry
key points to an install that is no longer there. This happens a lot with
firefox where a user was using a pre-installer build, then they switch the
installer which put firefox in a new location, deleted the old build but the
user hasn't set the new locaiton as the default.

In this scenario, when the user clicks on an http url in a mail message, our
call to the windows OS to open the URL fails and we end up bringing up the
helper app dialog, saving the link to disk and then opening it.

Other apps still seem to be able to bring up a browser. Maybe our system call is
wrong or there is something else we can try.
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.7
(Assignee)

Comment 1

14 years ago
Searching through Google, we could do what this site does:

http://www.mvps.org/access/api/api0018.htm

Bring up the windows app picker dialog.
(Assignee)

Comment 2

14 years ago
*** Bug 240222 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

14 years ago
my work around apparently worked on the branch (ignore any error returned by
ShellExecute). 

So this is now working in the latest-0.7 builds. Pushing out to figure out what
to do on the trunk.  
Target Milestone: Thunderbird0.7 → Thunderbird0.9
(Assignee)

Comment 4

14 years ago
*** Bug 246597 has been marked as a duplicate of this bug. ***

Comment 5

14 years ago
mscott, I see a problem with the branch build version 0.7a (20040613). dipa (on
the forums) suggested it might be related to this bug. When I click on a link in
Thunderbird it will not open Firefox even though Firefox is the default browser.

Clicking on links work IF and only IF Firefox is already running.

Comment 6

14 years ago
The same thing happens for me (like Bug 246597) where the open with dialog comes
up and a second window opens, even after upgrading from FireFox 0.9 RC to the
current 0.9 release.  I verified that FireFox thinks it is set as the default
browser.  The strange thing is that even if I choose "FirefoxHTML (default)"
from the drop-down and check "do this automatically...", the OK button stays
grayed out and I am forced to cancel or close the dialog box.  I guess this is
because there isn't an actual MIME attachment with a filename..?
(Assignee)

Comment 7

14 years ago
*** Bug 246928 has been marked as a duplicate of this bug. ***

Comment 8

14 years ago
In my case, Firefox comes up just fine, but the junk message comes up in
Thunderbird, too.

I even tried deleting Firefox, purging all instances of the string "Firefox"
from the Registry, and reinstalling 0.9.
(Assignee)

Comment 9

14 years ago
*** Bug 247099 has been marked as a duplicate of this bug. ***

Comment 10

13 years ago
I'm not seeing this bug anymore with Thunderbird 0.7.

Comment 11

13 years ago
I'm not seeing this bug anymore with Thunderbird 0.7. either,.. however FireFox
must now be running for it to work at all. still its an improvement :)

Comment 12

13 years ago
Hmmm, I can't reproduce that. I've started Thunderbird right after boot, and
then clicked on a link inside a message. Firefox opened.

Comment 13

13 years ago
sorry,.. it seems ok now. must have been a problem straight after installation.

Comment 14

13 years ago
WFM with 20040613 (0.7a) also, weird.

Comment 15

13 years ago
There is a thread of discussion in the Thunderbird support forums about some
related behavior: http://forums.mozillazine.org/viewtopic.php?p=698074

This is being reported with Thunderbird 0.7.2 and Firefox 0.9.2. Is there any
chance the recent changes are causing this newer problem?

Comment 16

13 years ago
I'm seeing this on the latest trunk nightly. I click on a link, and it opens the
link in my default browser (Firefox), but it also brings up the "helper app"
box, as if the file should be downloaded.

I wiped my computer entirely three days ago, and reinstalled the system and then
the latest trunk nightlies of Thunderbird and Firefox. I haven't installed any
new copies of Firefox since. So it simply can't be an old browser registry
setting. Unless you're saying that the current Firefox installers are bad?

Comment 17

13 years ago
I removed my profile, started from scratch, downloaded a few mails with URLs in
them, and the problem still occurred.

I used my Mozilla browser to set the default browser as Mozilla instead of
Firefox. Then I relaunched Firefox, which asked me to set it as the default
browser. After I did so, the problem went away, in that Thunderbird would no
longer open any URLs at all, just like the 0.8 branch build!

I then used the Win XP "Set Program Access and Defaults" to set the browser to
Firefox. No change. I then used it to set the default to IE. Thunderbird
launched links fine. Then I used the same to set the default back to Firefox. It
now works fine in Firefox as well!

Given what I said in comment 16, is something corrupting Firefox's registry
settings? However, links still launched fine in OE even if they wouldn't in
Thunderbird. Very strange.

Comment 18

13 years ago
It might be a Firefox registry problem: I myself had this problem when using FF
0.8 and it went away with 0.9, but a colleague of mine had it exactly the other
way around. He switched back to 0.8 and it was "solved".
(Assignee)

Comment 19

13 years ago
moving to after 1.1 since I had a 'fix' in the aviary branch for thunderbird.
Just need to figure out what to do on the trunk
Target Milestone: Thunderbird0.9 → Thunderbird1.1
Darin and I think you're throwing away the errors in the wrong spot (on the
branch). It probably doesn't make a whole lot of difference, but
nsOSHelperAppService::LoadURL should return the ShellExecute error and then
nsWebShell::OnLinkClickSync() should always return early for a non-exposed
protocol regardless of success or failure (it's non-exposed, we already know we
don't want a browser window to open).

fixes for bug 263546 will probably take care of this.
Depends on: 263546

Comment 21

13 years ago
*** Bug 263833 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

13 years ago
i think this is no longer an issue on the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.