Closed Bug 239965 Opened 20 years ago Closed 19 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird1.1

People

(Reporter: mscott, Assigned: mscott)

References

Details

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.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.7
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.
*** Bug 240222 has been marked as a duplicate of this bug. ***
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
*** Bug 246597 has been marked as a duplicate of this bug. ***
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.
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..?
*** Bug 246928 has been marked as a duplicate of this bug. ***
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.
*** Bug 247099 has been marked as a duplicate of this bug. ***
I'm not seeing this bug anymore with Thunderbird 0.7.
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 :)
Hmmm, I can't reproduce that. I've started Thunderbird right after boot, and
then clicked on a link inside a message. Firefox opened.
sorry,.. it seems ok now. must have been a problem straight after installation.
WFM with 20040613 (0.7a) also, weird.
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?
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?


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.
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".
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
*** Bug 263833 has been marked as a duplicate of this bug. ***
i think this is no longer an issue on the trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.