Closed Bug 216252 Opened 21 years ago Closed 4 months ago

Thunderbird seems to not respect the default browser set in Linux Desktop Environment preferences

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: toralf, Unassigned)

References

Details

Attachments

(5 files, 4 obsolete files)

"htmlview" script
2.42 KB, application/octet-stream
Details
Script to determine KDE user's browser preference.
1.00 KB, text/plain
Details
gnome-moz-remote.c
25.75 KB, text/plain
Details
New XRemoteClient fix
1.18 KB, patch
Details | Diff | Splinter Review
Update
6.22 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913
Build Identifier: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913

With Linux version of Thunderbird, URLs are not opened in browser when clicked.
Yeah, I realise that everyone knows about this; I just wanted a Bugzilla entry
for to be able to make some suggestions...

Reproducible: Always

Steps to Reproduce:
OK, here goes...

First of all, the browser selection routines are dependent on the desktop
environment, as far as I know. With GNOME, you'd use gnome_url_show, which is
documented in
http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-url.html.

A GNOME-only variant of LoadUrl would look something like this:

NS_IMETHODIMP nsOSHelperAppService::LoadUrl(nsIURI * aURL)
{
    const char *url=aURL->something();
      
    gnome_url_show(url, &err);
    if (err) {
         g_print(_("Error showing %s: %s\n"), url->url,
                    err->message);
        g_error_free(err);
        return NS_ERROR_FAILURE;
    }
    return 0;
}


where aURL->something() should be replaced by something that will turn an nsIURI
into a plain-text version of the URL. I'm sorry, but I don't know how to use the
nsI classes, and what method to call is not obvious from the class definition.

The disadvantage of this is of course that you'll need to link with libgnome,
and also add separate branches for KDE etc. An anlternative would be to execute
something like 'htmlview' supplied with Red Hat Linux (more on that later.)
Attached file "htmlview" script — 
"htmlview" is a script that tries to open an URL in the user's preferred web
browser, or the first one available from a list of well-known browser if
nothing is set up. The version supplied with Red Hat Linux 9 is attached here.
It might be  executed via a system() call in
nsIExternalProtocolService::loadUrl() in order to avoid including
desktop-specific calls.
duplicate of 213406
*** Bug 213406 has been marked as a duplicate of this bug. ***
Note that "err" in the example code would be declared as
  GError *err;

Also, you want just "url", not "url->url" in g_print() call.
If I could vote for this bug I would.  This is a really annoying bug that I
really hope is fixed soon!
There is a problem with htmlview. It appears not to be smart enough to use 
an existing session of the preferred browser, but instead tries to lauch another 
instance (which won't work). gnome-moz-remote otoh has the right semantics, but 
is of gnome-specific (but does not require linking to any gnome libraries). Why 
not do this:
1. Figure out whether we are running gnome, kde, cde , or none of them. 
Check for a "gnome-session" process for example. I assume there is a similar
process for kde. For cde, it would be "dtsession".
2. If gnome, use gnome-moz-remote.
3. If kde or cde, use whatever the kde or cde equivalent is.
4. Othewise give up perhaps after trying a few things as in htmlview. 

I was about to implement the htmlview way, but then discovered that 
is isn't that smart. By the way, as for how to get the string out of the 
nsIURI, look at the Windows implementation. Doesn't the GetAsciiSpec() 
method access the attribute you want and then the get() method on the resulting 
nsCAutoString gives you a string?
Attached patch Test implementation (obsolete) — — Splinter Review 
This is an implementation which works well under GNOME (it opens the URL in a 
new tab if the preferred browser is running and is mozilla, firebird or
netscape (otherwise it launches it).
It uses some of the ideas from htmlview (e.g. the gconftool-2 command is taken 

from it). If the user is running KDE, the kfmclient call here appears to 
just use konqueror, so this needs to be fixed. It is possible for a KDE user to

express a preference (KDE Components->File Associations->text->html), but I
have 
not yet succeeded in determining how to query the pref. Also, there is no 
logic here yet for CDE. I have left in numerous print statements to make it 
easier to see how it works. I hope this stimulates some further discussion. 
-- David
I think htmlview relies on the fact that in the Red Hat distribtion,
/usr/bin/mozilla itself will make sure only one instance is running.
A couple of comments on the attached patch
1) Once you've determined that GNOME is running, you could do 

GError *error;

gnome_url_open(urlSpec.get(), &error);

Which is a lot simpler, and better in the sense that it hides details about
GConf structure etc. The disadvantage is that the application needs to be linked
with libgnome. dlopen() might be used to avoid that, but raises issues of its own.

2) I think gnome-moz-remote has some built-in magic to choose between browsers,
but I'm not sure if it's synced with the GConf stuff, or is general enough too
be called directly. If it isn't, maybe it would be better to avoid using it at
all, and call mozilla-xremote-client instead.
Just a suggestion:
What about configuring if Thunderbird should use it's "brother" Firebird or the
system default browser (however this can be determined) to open URls? I think it
is not bad idea, if Firebird/Thunderbird know each other very well and can use
the counterpart directly (may with a configurable path to Firebird in
Thunderbird and a configurable path to Thunderbird in Firebird).

Maybe this way:

Open URLs
 x Use Firebird |/path/to/firebird| ...
 o Use system default browser
A few comments:
1. I avoided gnome-url-open because of the library issue. 

2. I have RedHat 9 and if I try to launch mozilla while it is running, I get a 
profile dialog. If I ask for the same profile, it says I can't do that (lock
file, I think). That is why I think it is important not to just launch without
checking (although notice I do just that under KDE since I have not yet figured
out how not to).

3. I've had a hard time finding documentation for gnome-moz-remote, but
empirically, I now think it does not check the configured pref at all, but uses 
whatever mozilla-like browser happens to be running. That is why I only used it 
in my code in that situation. I gave up trying to understand what 
it does if no browser is running. I am very intrigued by this
mozilla-xremote-client, especially because it ought to work under KDE as well as
GNOME. Can you point me to some documentation on it? I tried --help and got nothing.

4. As for configuring a preference, I read a thread somewhere (I forget where)
on this subject which led me to believe that the TB developers really did not
want any choice mechanism specific to TB itself, but rather considered it a
requirement to get the pref "from the OS", so I am trying to satisfy that
requirement. I definitely want Firebird to be it, but the code I submitted does
exactly that since I chose it under GNOME preferences.

gnome-moz-remote used to (GNOME-1) have a separate config file that could not be
changed via the GUI, to control what command to run. I'm not sure about the
GNOME-2 version. I notice that gnome-moz-remote is included in one of the
GNOME-1 compatibility packages, though, so maybe it isn't maintained at all anymore.

I don't know a lot more about mozilla-xremote-client than what can be deduced
from the calls in Red Hat's mozilla starter script, i.e.

MOZ_CLIENT_PROGRAM="/usr/lib/mozilla-1.2.1/mozilla-xremote-client"
    $MOZ_CLIENT_PROGRAM 'ping()' 2>/dev/null >/dev/null
      exec $MOZ_CLIENT_PROGRAM 'xfeDoCommand(openInbox)' \
      exec $MOZ_CLIENT_PROGRAM 'xfeDoCommand(composeMessage)' \
  exec $MOZ_CLIENT_PROGRAM "xfeDoCommand(openBrowser)" 2>/dev/null >/dev/null
    exec $MOZ_CLIENT_PROGRAM "openurl($opt)" 2>/dev/null >/dev/null
  exec $MOZ_CLIENT_PROGRAM "openurl($opt,new-window)" 2>/dev/null >/dev/null

Also, http://www.mozilla.org/unix/remote.html contains some information about
the remote protocol. Note that one of the links also contain information on how
to use that protocol directly from a C program (i.e. without executing external
commands) - could be what we want here, although I'm not sure it's worth the
effort (then again, perhaps Thunderbird has some higher-level routines that
could be called.)

Another alternative would be to write a simple app that would pass on its
arguments gnome_url_open(), and execute that. I've always been thinking that
something like that ought to be included with GNOME, actually. htmview provides
nearly the same functionality, but not quite.

Thanks Toralf for valuable information. I now understand what you said earlier 

about RedHat modifying the mozilla startup to avoid the "Are you running?"
issue. I see now that mozilla-xremote-client can and should replace
gnome-moz-remote in my scheme. 

Meanwhile, this attachment is, I think, another piece in the puzzle. It figures
out what the KDE user's preferred browser is. So all that remains is to check
and see if that is running and mozilla-related, and if so use
mozilla-xremote-client, otherwise just launch (same logic as for GNOME). I know
there is an obvious criticism to this script, namely that it is based on the
current data structure. If there were a command line query (like gconftool-2),
that would certainly be better, but I could not find one. Or even better, if
there were a command that would simply load a URL into the preferred browser
(like that one you discovered will be in libgnome-2.4!), but the closest thing
I could find to that was "kfmclient exec (URL)". That does launch the right
browser, but it feeds it a damaged copy of the page instead of actually loading
the URL. Anyway, I'll post an updated patch once I get it all working.
Well, the only remaining problem is that mozilla-xremote-client doesn't really
work for this after all. I had discovered earlier that using the "-remote"
option on the browser doesn't work either. In both cases, the system() call
hangs; ctl-C breaks the hang, but then you get a TypeError alert.
gnome-moz-remote on the other hand works fine, but only under GNOME, so I
currently know of no way (from TB) to load a URL into an exsiting Firebird
instance, for example, in the KDE case. I just discovered a thread in the
"Firebird General" MozillaZine forum pointing out that the problem is tied to
having Thunderbird running (which is pretty hard to avoid in our situation)!
They said that what was happening is that the remote request is going to TB
instead of the browser. Perhaps there is a way to make that not happen.
*** Bug 219083 has been marked as a duplicate of this bug. ***
Yes, of course, Thunderbird also identifies itself as a Mozilla window, and may
get in the way. I don't think it ought to pick up *mozilla* request, but I put
the fact that it does down to the fact that it just isn't finished yet.

Anyhow, I think when the "remote" command detects several instances of mozilla,
I think its completely arbitrary which of them gets the request. The *protocol*
will however allow you to determine which one you want. Also, netscape used to
have an "-id" option, taking an X server window id as argument, that might be
used to specify which window you wanted to contact. I'm not sure if it works
with Mozilla. (I'll test later.)

I'm starting to think that it would be better to use the remote protocol
directly instead of executing external commands (even when trying to determine
if mosilla is running.) http://wp.netscape.com/newsref/std/remote.c
shows how it is done, or used to be done; I believe this file is somewhat dated.

I notice that Thunderbird also accepts the -remote argument, though, so
everything that is needed should be there already.
Attached file gnome-moz-remote.c — 
Alternatively, we could just use the gnome-mozilla-remote source code, which is
attached here.

Note that the program uses GNOME calls, but only to find out how to execute a
new browser, as far as I can tell, and we don't need that section of the code.
I agree that it is preferable to issue the remote request directly (without
using a shell process) and that the code is already there. I think it is in
nsAppRunner.cpp, around HandleRemoteArguments() about line 1417. This is the
code that is used if you had invoked TB or whatever with -remote (and no, the
-id option is not supported). I think it's also the code used by
mozilla-xremote-client. So I think you could do the same thing in LoadURL() that
is being done here. Now, the implementation of this is in XRemoteClient.cpp.
That contains the code that tries to pick the right window (and currently may
incorrectly pick TB), specifically, in XRemoteClient::FindWindow(). I should
think you could find some attribute that would clue you into the fact that you
were looking at a TB window. After all, gnome-moz-remote always figures it out
correctly. Thanks for posting gnome-moz-remote.c. I've been staring at it (and
comparing with FindWindow()) trying to figure out why it never picks the TB
window, but have not yet. Maybe run it under gdb with TB the only moz-like thing
running, and watch what it does when it gets to the TB window?

This simply looks at the WM_NAME attribute of a window which would have been
picked before. If it contains thunderbird or Thunderbird as a substring, we
keep on looking. I tested with the standalone mozilla-xremote-client, and it
now does the right thing even if there is a TB window up. The fix also goes
into libxremote_client.so, so if we manage to use the XPCom method in LoadURL,
that should get the fix too. Some may object to using this method of nailing
the TB window (might be better to give it a special property you could check
for), but this does work at least. The printf shows in my testing that the name
is "thunderbird-bin" for the TB window, which surprised me. I was expecting the
long name actually displayed in the window decoration, which is what I get for
the Firebird window.
Good news and bad news. Good news is that I have the xremote stuff working in
LoadUrl via XPCom rather than using system() on a shell command (pretty much
copied from nsAppRunner.cpp and made a few obvious changes).

The bad news is that the last attachment I posted has what now seems like an
obvious flaw: If the current browser window is looking at a page which is about
.. er ... Thunderbird, then "Thunderbird" will be a substring of the WM_NAME
property. Oops. I think I can fix that (look for "thunderbird" at the beginning
or "Thunderbird" at the end). Still seems kind of kludgy, so it should probably
be changed to a more solid approach.

Will post a new patch once I've cleaned it up a bit. I haven't tested it for KDE
yet but I believe this should work there too.

This contains the correction I mentioned before. It only rejects a window 
if the name is exactly "thunderbird-bin" or ends with " - Mozilla Thunderbird".
Attachment #131416 - Attachment is obsolete: true
Attached patch New LoadURL implementation (obsolete) — — Splinter Review 
This version works for both GNOME and KDE. In the KDE case, it depends on 
kdebrowser.pl being in dist/bin. The XRemoteClient fix is also required. When
the user's preferred browser is already running and is mozilla-like, the URL is
loaded via X Remote into a new tab in the existing browser instance. I've still
got a lot to learn about Mozilla coding practices. Could someone please tell me
how not to hard-code those include file paths? So far I haven't figured it out.
Any comments welcome of course.
Attachment #131049 - Attachment is obsolete: true
Looks quite good.

Just one minor point: Instead of doing system("ps ...") too look for the
mozilla, it would probably be better to try X remote stuff directly, and try to
launch the browser if that fails.
I like that idea. Maybe I'll give it a try this weekend.
Thanks

This was inspired by the recent suggestion by Toralf Lund. Once the preference
is known, if it is mozilla-like, we try to use XRemote to load the URL into a
new tab on something that is already running. Of course, if the user's
registered preference is mozilla, but he happens to be running netscape, then
netscape is what will be used. I think that may even be desirable. If that
fails (e.g. nothing is running), or if the preference is not mozilla-like, then
we launch the preferred browser. There is also a new feature here: If the user
is running neither GNOME nor KDE, but has set X11BROWSER to her preference,
that will be honored. That idea is from htmlview. If X11BROWSER is unset, we
try Firebird.
Attachment #131548 - Attachment is obsolete: true
QA Contact: asa
Attached patch Update — — Splinter Review 
Since this is still open, I'm posting my latest revision. These are the
changes:
1. This patch is against rev 1.38. It checks the scheme and calls a new
function 
if it is http, https, or ftp, otherwise proceeds with what 1.38 was doing. The
new function contains an update of what I had in loadUrl() before.
2. Try immediately to use the XRemoteClient method. Don't bother checking for
which desktop, preferred browser unless this fails. This makes the previous
"Mozilla-like" test unnecessary.
3. Use Mozilla string classes instead of C-style fixed size character arrays
(except for popen()/fgets() which I do not know how to do "in C++").
Issues:
1. The method used here for determining which desktop is in use assumes that TB
is running on the same node as the desktop (not necessarily true). I wonder if
this could be done instead using inter-client communication (which the
XRemoteClient code does).
2. I'm not sure having the XRemote logic bypass TB windows is the right
solution. For example, Abiword triggers the same old Type Error when you try to
go to its help page. Maybe TB should have a "Mozilla Mail Version" window
property instead of a "Mozilla Version" property. Then you wouldn't run into
the TB window unless you were specifically looking for it.

If someone already has a solution to this ready to go for 0.3, maybe this bug
should be closed. Otherwise, I would really appreciate any feedback/criticism.
Attachment #131817 - Attachment is obsolete: true
*** Bug 223241 has been marked as a duplicate of this bug. ***
As there are some patches: should this work in the 0.3 build? I still cannot
open URLs in mails on Linux. Suse 8.2, KDE 3.1.4
Here is an update on how I am handling this problem. I use Gnome and recent
trunk versions (since r1.39) of nsOSHelperAppService.cpp use the Gnome preferred
browser for a gtk2 build. The trouble with that is that nothing is checking to
see if it is already running so it will fail the second time unless you choose a
different profile (assuming FB, say). But using RedHat's approach, there is an
easy workaround to that. Just declare your "preferred browser" to be a script
which does something like:

url=$1
MozillaFirebird -remote "OpenURL($url, new-tab)" || MozillaFirebird $url &

Or, you could do a RedHat-style mod to the FB startup script. That would work
except for the old problem that Thunderbird is running and responds to the
interclient communication query for a window with the _MOZILLA_VERSION property
but is not really a browser and so just bombs with a "type error". The fix which
I posted before to this (checking the WM_NAME property) has 2 problems:
1. You can't count on what the WM_NAME will be.
2. Worse, this doesn't help for other applications such as Abiword and
OpenOffice which try to open a URL using remote control without any additional
check, and so get the Type Error if TB is running (Is there a bug open for this?)
But there is a simple workaround: In a TB-only CVS tree, just change the atom to
something not identical to _MOZILLA_VERSION. Since we are assuming a gtk2 build
here, the file to modify is:
widget/src/gtk2/nsGtkMozRemoteHelper.cpp. Just change 
#define MOZILLA_VERSION_PROP   "_MOZILLA_VERSION" to
#define MOZILLA_VERSION_PROP   "_MOZILLA_MN_VERSION", for example.
A similar niggle is that if the user also has mozilla appsuite running, then
that may also respond, in this case by bringing up a browser window.

I have firebird, thunderbird & mozilla appsuite running - the latter merely to
provide a calendar - and when I use a script to use firebird -remote a new
mozilla browser window opens.
Hmm... what about simply adding

pref("network.protocol-handler.app.http", "/path/to/MozillaFirebird");

to all.js?
No. The consensus is that URLs should be opened in the whatever browser the user
prefers, and configures as default in the desktop environment. Separate config
in Thunderbird or a hardcoded application is a bad idea.
Toralf, I understand what you are saying, but I was not suggesting hardcoding
something in all.js. I was just suggesting a hack that people can use now.

However, I /would/ like Thunderbird to be able to invoke a user-specified
program, with UI configure this, at least on Linux or Unix builds (like the
Seamonkey application helpers).

This is because it's extremely hard to come up with a solution that works
everywhere. We could possibly cover gnome and kde, but what about the other
dozens of window managers used on Linux and other unix-like OS's?

For example, I'm (unfortunately) using Gnome 1.x, and the GTK2 partial fix that
is in the current trunk doesn't work for me. And what about people using
WindowMaker or anything else?

The unix way has always been to let the user be in control of the programs he
wants to use. I'm not against gnome and/or kde integration, but I think we
should also provide a custom path for people want to configure things themselves
and know how to do it.
Well, yes, a separate config might be called for in certain cases. It should be
something used if, and only if, an alternative to the "user env"/external
default is required, though; you shouldn't need to configure it explicitly to
use the GNOME default or whatever, like you have to do with a certain Mozilla
based browser I'm trying to stop using...

A GUI for a config like that might be however against the design pilosophy of
the Mozilla "birds", which seems to be to have small and clean config dialogs
with a limited number of options useful to most users - but allow a certain
degree of extra configurability to advanced users via config files etc. (A sane
approch, I think.)

An of course, the unix way has also in many ways been *not* to require a lot of
setup operations by each and every user for each and every application...
Depends on: 226071
*** Bug 227961 has been marked as a duplicate of this bug. ***
This one seems to belong under this:

Distribution: Debian testing/unstable

If no Galeon windows already open, Galeon crashes on startup when a
http-address is cliked in mozilla thunderbird

Steps to reproduce the crash:
1. Set galeon default browser (for Thunderbird at least)
2. Close all Galeon windows
3. Click some http:// -address in some email

Expected Results:

Galeon starts and crashes at startup

How often does this happen?

With this procedure (steps 2,3) Two times out oof two, with different
sites, two different days etc.

Additional Information:

When there is a galeon window open, a new is opened and the site loaded
to it.

Mozilla Thunderbird version 0.5 (20040306)
Galeon 1.3.11a
Not certain if this is new or not.
With thunderbird 0.7.1 on SuSE 9.1 the workaround with the shell script launcher
doesn't work.

The launcher contains:

!/bin/sh

export MOZILLA_FIVE_HOME="/opt/MozillaFirefox"
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MOZILLA_FIVE_HOME

url="$1"
if [ "x$url" = "x" ]; then
  url="about:blank"
fi

if $MOZILLA_FIVE_HOME/mozilla-xremote-client openURL\("$url"\); then
  exit 0
fi
exec $MOZILLA_FIVE_HOME/firefox "$url"

The LD_LIBRARY_PATH was required because mozilla-xremote-client didn't find one
of its shared libs.

This script works fine run from the command line.

Thunderbird prefs.js contains the line:

user_pref("network.protocol-handler.app.http", "/opt/launcher");

Clicking on a URL embeded in an e-mail has no effect at all.

An extra line was included in the shell script:

           date > /tmp/zzz

to verify that the script was actually run - it was not, the file /tmp/zzz never
appeared (unless the script was run from the command line.


(In reply to comment #39)
> Not certain if this is new or not.
> With thunderbird 0.7.1 on SuSE 9.1 the workaround with the shell script launcher
> doesn't work.

Hm, I also use Suse 9.1 and Thunderbird 0.7.1 and Firefox 0.9.1. For me the
workaround with the script still works. Here is my script, which works
(unchanged since Thunderbird 0.5):

#!/bin/sh
export MOZILLA_FIVE_HOME=/usr/local/Firefox
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MOZILLA_FIVE_HOME
url=$1
[ -z $url ] && url=about:blank
$MOZILLA_FIVE_HOME/mozilla-xremote-client openURL\($url\) && exit 0
exec $MOZILLA_FIVE_HOME/firefox $url
Flags: blocking-aviary1.0?
Using:
  Thunderbird 0.7
  Firefox 0.9
  Fluxbox 

I have a script:
   firefox -a firefox --remote \"openURL\($page,new-tab\)\"
Script solutions work well from commandline, but from Thundebird, a Save-Dialog
opens, saves the link to a temporary file (/tmp/viewtopic-php) and then opens
the oh so pretty 'choose user profile' - Dialog.

Can't I open a link in a self-defined browser, without saving it to disk???
(In reply to comment #41)
> Using:
>   Thunderbird 0.7
Updated to 0.7.1 with same result.
This affects FreeBSD and probably other *nix platforms as well.
(In reply to comment #42)
> (In reply to comment #41)
> > Using:
> >   Thunderbird 0.7
> Updated to 0.7.1 with same result.

Well - got it run.
This isn't a good solution in general but just works for me - having no
default-browser in 'fluxbox'-Window-Manager.
It's patched from different sources so thanks to anyone, here is my script
'run-browser.sh' .

#!/bin/bash
#
#
url=$1
running=$(ps h -C firefox >/dev/null && echo running)
if [ "x$url" = "x" ]; then
	url="http://www.google.de/"
fi

if [ "x$running" = "x" ]; then
	PRG="firefox "
	param=" $url"
	RUNNING="no"
else
	PRG="firefox -a firefox "
	param=" --remote \"openURL\($url,new-tab\)\""
	RUNNING="yes"
fi

echo "----- $(date) ----
PRG:		$PRG
URL:		$url
running:	$RUNNING
param:		$param
$PRG $param
" >> /home/stefan/.runmoz.log

$PRG $param
################# end of script.
It tests for parameter and adds a default if there is none.
Test for already running instance (on a local machine). If yes uses new tab.
And logs to find problems.

First it only worked from commandline, not from thunderbird.
Now I found a stupid error in my ~/.thunderbird/default.twz/prefs.js : 
    user_pref("network.protocol-handler.app.http", \
    "/home/stefan/bin/run-browser.sh");
I had written 'run-browser' - without extension.

Thanks for your patience - but the mechanism is pretty complicated and to
indirect in my opinion - a modification-option in the thunderbird-context-menu
would be more easy to find and to test. 
(In reply to comment #44)
> Thanks for your patience - but the mechanism is pretty complicated and to
> indirect in my opinion - a modification-option in the thunderbird-context-menu
> would be more easy to find and to test. 

Yes, I agree! As there is no standard desktop environment on unix, we do not
really have a chance to get a reliable information on the standard browser
application. I would prefer a setting as in OpenOffice: A combobox with several
preconfigured browser applications (Firefox, Galeon, Konquerer, Opera and maybe
some more) and an edit field with a directory selector to specify the directory
of this application. This should make it easy for the not so experianced user to
set the browser in Thunderbird without scripting and editing config files.

I know that the settings should be as minimal as possible, but I see no other
userfriendly way doing this, and we should be user friendly, I suggest.
Scott, this seems like a pretty big problem on Linux. Is this something that's
got a prayer of being resolved for 1.0? I suspect that if we failed to launch
the default browser on Windows when a link in a mail message was clicked that
we'd be all over that. 
(In reply to comment #45)
> (In reply to comment #44)
> > Thanks for your patience - but the mechanism is pretty complicated and to
> > indirect in my opinion - a modification-option in the thunderbird-context-menu
> > would be more easy to find and to test. 
> 
> Yes, I agree! As there is no standard desktop environment on unix, we do not
> really have a chance to get a reliable information on the standard browser
> application. 
I don't think this is true. While there is not one standardised desktop, the
problem is not as big as you make it sound. Not on Linux, anyway - I think you
can be 100% sure there that the "not so experienced user" is using either GNOME
or KDE. Finding out which if these is running, and getting the appropriate
browser config should not be that hard, i.e. your inexperienced user should
never need to hack config files. (If the user is not running GNOME or KDE, I
think we can safely assume he won't think that updating config files by hand is
a problem - in fact, he may even prefer doing things that way.) And the GNOME
case at least works already with recent Thunderbird releases! I'm not entirely
sure about the desktop usage on other Unix-like platforms, but the major vendors
support GNOME these days, as far as I know.
(In reply to comment #44)
> (In reply to comment #42)
> > (In reply to comment #41)
> > > Using:
> > >   Thunderbird 0.7
> > Updated to 0.7.1 with same result.
> 
> Well - got it run.
[ ... ]
>
> Thanks for your patience - but the mechanism is pretty complicated and to
> indirect in my opinion - a modification-option in the thunderbird-context-menu
> would be more easy to find and to test. 
Like I said already, I don't quite agree. I do agree that the setup is a bit too
indirect, though. I think that the major problem is the need for a special
script (and this problem isn't resolved directly by adding a config GUI),
however, and that this isn't really a Thunderbird issue. In my opinion, Firefox
or Mozilla should *always* be started in the manner outlined in the scripts
mentioned here. I think maybe there is a related RFE for Firefox already - if
not, I'll add one. Fortunately, many OS-bundled variants of Mozilla do the right
thing already...
Depends on: 256715
I just installed Firefox aviary branch 20040904 and Thunderbird branch 20040904
on Windows XP with Service Pack 2. I have made both apps the default on my
system. But the links in Thunderbird still don't open Firefox if Firefox isn't
runing allready. If it is open then the new window with link is opened.
This bug is to track the Linux issue.  A seperate bug report should be filed (or
found) if Thunderbird is failing to launch Firefox on Windows.
I am using Thunderbird version 0.8 (20040916), and the following shell script:
#!/bin/sh

export MOZILLA_FIVE_HOME="/usr/bin"

url="$1"
if [ "x$url" = "x" ]; then
  url="about:blank"
  fi

  if $MOZILLA_FIVE_HOME/mozilla-xremote-client openURL\("$url"\); then
    exit 0
    fi
    exec $MOZILLA_FIVE_HOME/firefox "$url"

###end of script

Clicking on a link, however, does not load the actual URL, but rather a temp...
For example, I click on http://www.ioniacounty.org/bbpark/ and the (new) FIrefox
window opens file:///tmp/1jl40a3u-1.html

The resulting page has all the text content of the real URL, but no pictures,
and any links which are not fully spelled out (such as href="./newpage.html") fail.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** Bug 274421 has been marked as a duplicate of this bug. ***
Further to my comments about the ibability of Linux versions of Thunderbird to
activate the default browser on clicking a link.  Trying the same test on a
Mandrake 10.0 system, Evolution came up when the link was clicked.  (The program
controls were also under Tools|Options)

On this system (SuSE 9.1) the links are not clickable.

Andrew
*** Bug 279065 has been marked as a duplicate of this bug. ***
First, I have to quite disagree with comment #47.  There exist people who don't
like KDE or GNOME because of their integrated nature, but who also don't like
being bothered writing config files and who want everything to just work.  I am
one of those people.

What Linux/Unix needs is a command-line program to open any URL (including the
file:// protocol for opening local files) with an appropriate program, looking
up the program in a database (which might be a simple file) which the user can
modify.  It has to be command-line to avoid being tied to a specific desktop
environment and for people who don't use a GUI.  The long-term solution, then,
is to write that program, and supposing it's called "open", call system("open
<url>") to open a URL (in C/C++).

Until a program like that exists, the short-term solution should be to have a
configuration option in Thunderbird to run a command to open a URL.  The default
of that option would be firefox.  There's no other user-friendly
environment-independant way to do it that I can think of, given the above
mentioned limitation of Linux/Unix.

Also, it has been discussed that the web page should be opened in an existing
browser window.  What if people don't like that?  I prefer that when I click a
link, a new window pops up and gets the focus, unless the link is clicked from a
browser.  Otherwise I might lose a web page I was looking at.  I would think the
web browser can and should handle whether to open a new window; i.e. if it's
called when it's already open, it knows whether it should use an existing window
or open a new one.  I seem to remember a configuration option in firefox for
whether to open new windows (but maybe it was just the old mozilla, and/or
Internet Explorer).
I think you get this wrong. The question is really whether you should force
GNOME or KDE users, i.e. the wast majority, to use a special config option in
thunderbird, even if there are some people who don't like these environments.

If there should be a config option for this at all, it should be one that will
override the default of taking the browser from the GNOME or KDE setup, not one
that everyone has to maintain indepentently of their desktop config, IMO.

Fortunately, the desktop integration is there already, at least for GNOME.

I'm actually considering if I should mark this bug as fixed...
OK, it doesn't bother me if you want to first do a check to see whether KDE or
GNOME is running, and if so, use the default from them.  But I still think an
option is a good idea, with a note beside it that the default browser of your
environment will be used instead, if possible.  The point is that a default
browser is a really a system-wide property, not a property of a specific desktop
environment, so it should not be assumed that people are using a desktop
environment which specifies a default browser.

On our systems, we don't use Gnome/KDE.  For our purposes, adding the following
to the user configuration is acceptable:

user_pref("network.protocol-handler.app.http", "firefox");

However, I've run into an issue with this, and this issue will probably affect
any mechanism used in order to solve this problem.  If the user goes to the
"Tools" menu, and selects "Themes" and then chooses the link for "Get More
Themes", it is now Firefox that will go to the themes site, and when the user
attempts to install the theme, an attempt will be made to install the theme in
Firefox!  The user gets a message something like "cannot install a thunderbird
theme in firefox".  How might I get around this so that the theme is installed
directly in thunderbird?  I can't think of any way.

Jason.

On our systems, we don't use Gnome/KDE.  For our purposes, adding the following
to the user configuration is acceptable:

user_pref("network.protocol-handler.app.http", "firefox");

However, I've run into an issue with this, and this issue will probably affect
any mechanism used in order to solve this problem.  If the user goes to the
"Tools" menu, and selects "Themes" and then chooses the link for "Get More
Themes", it is now Firefox that will go to the themes site, and when the user
attempts to install the theme, an attempt will be made to install the theme in
Firefox!  The user gets a message something like "cannot install a thunderbird
theme in firefox".  How might I get around this so that the theme is installed
directly in thunderbird?  I can't think of any way.

Jason.

Actually, it doesn't let you (or at least doesn't let me) configure KDE with a
default browser and have Thunderbird use that.  I went to KDE's "Component
Chooser" (part of Control Center), selected Web Browser and chose Mozilla
Firefox from the K Menu.  Thunderbird still won't do anything when I click a URL.

By the way, if Thunderbird can't decide what browser to open, it should at least
give a message saying as much and say how to rectify the situation.
Jason: your suggestion, though it seems like a good one, didn't work for me.  I
assume you meant to go to http://about:config and create a new String field
named network.protocol-handler.app.http with value "firefox"?  Even after
closing firefox and thunderbird and restarting them, URLs didn't open from
thunderbird.  I even checked that the line got added to
~/firefox/x6v07agk.default/prefs.js, which it did.
All links in email as well as the Release Notes entry in the Help menu do not open a web browser, probably because Linux has no idea what a "default browser" is. A field in the pref panel to specify the path to our lovely browser would probably fix the problem. As all links are broken in Tb, I'm requesting to take this for Tb2.
Flags: blocking-thunderbird2?
(In reply to comment #62)
> All links in email as well as the Release Notes entry in the Help menu do not
> open a web browser, probably because Linux has no idea what a "default browser"
> is. A field in the pref panel to specify the path to our lovely browser would
> probably fix the problem. As all links are broken in Tb, I'm requesting to take
> this for Tb2.
What type of Linux setup are you on?

On the ones I've been using, this has worked out-of-the box for a long time now. And Linux certainly has an idea about the "default browser". Actually, what has been a bit of a problem is rather that there may be too many different ideas - although the setup of all this is being standardised. However, Thunderbird has been able to sort it all out and get the correct "default" since before version 1.0, in my case. And recent versions of Firefox will (optionally) update the default browser config for you, I think.
I'm running KDE. And the reason Tb is unable to open links in Fx is maybe closely related to bug 297841.
(In reply to comment #64)
> I'm running KDE. And the reason Tb is unable to open links in Fx is maybe
> closely related to bug 297841.

I thought I verified that KDE was supported earlier, but perhaps not... The code submitted here does try to support KDE, but only by executing a script called "kdebrowser.pl" (from the Thunderbird install directory), which is expected to find the actual viewer from KDE's config. There is no such script in my Thunderbird installation...

This is obvioulsy somewhat related to bug 297841, but it should be possible to pick up a default browser from KDE even without a fix for that problem, since there are other ways to specify it.


(In reply to comment #0)
>
> With Linux version of Thunderbird, URLs are not opened in browser when clicked.

I recently ran into this problem with a new install of Fedora Core 6.  The answer in my case was so simple, but it drove me nuts trying to find the documentation.

The first place to check is in Firefox.  Even though the option in Firefox was turned on for "Check to make sure Firefox is the default browser", Firefox evidently does not make that check if the default browser is empty.  Manually forcing Firefox to be the default browser (Edit>Preferences>Main>System Defaults>Check Now) solved the whole issue for me.

If this patch is still something that's going to be useful for Linux users, I'd suggest getting the review process going on it.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
QA Contact: front-end
Really funny that that really important issue is still unsolved for now 4 years.

Could be so easy to solve: simply add an form for specifying and command (maybe choose between external handler vs. internal javascript) and kick off the whole default-browser-blabla.

Probably too simple ;-O

(In reply to comment #68)
> Really funny that that really important issue is still unsolved for now 4
> years.
As I've said earlier, it has actually been "resolved" for GNOME users for about 3 1/2 of those 4 years.
> 
> Could be so easy to solve: simply add an form for specifying and command (maybe
> choose between external handler vs. internal javascript) and kick off the whole
> default-browser-blabla.
That would be pretty dumb, since the default browser method works very well indeed for many users in the current version.


And what about people who do not run GNOME?

There should be an option 'path to html browser' or something similar. Would be network.protocol-handler.external.* the right place to put that in?
The solution is so simple: put these lines into your user.js:

user_pref("network.protocol-handler.app.ftp", "/opt/firefox/firefox");
user_pref("network.protocol-handler.app.http", "/opt/firefox/firefox");
user_pref("network.protocol-handler.app.https", "/opt/firefox/firefox");

By default these options do not exist in prefs.js.
See http://forums.mozillazine.org/viewtopic.php?p=3115001#3115001 for the backstory for why I'm posting here.

I don't doubt that this problem has been solved for GNOME users. I'm a GNOME user at home, but at work I am using KDE which apparently is misconfigured (assuming Thunderbird has both KDE and GNOME heuristics to guess at the default browser). But new Thunderbird users don't know that "Mozilla Thunderbird Help" will fail silently because Thunderbird could not obtain the default browser using its heuristics.  This is a very problem for new user adoption if the very first thing they need to see (which is the online help manual even if it is on some HTTP server somewhere) fails with no diagnostics dialog box indicating why it failed.

I would not want to have to manually edit a preference file either, but I would have like Thunderbird to at least popup a dialog box telling me that is what I had to do at bare minimum.  One step up from that would be to prompt for the path to the URL, and automatically save that in the users preferences for future invocations.

bgoodr

Why doesn't thunderbird use xdg-open (http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html) ?
Assignee: mscott → nobody
Does Firefox not have code to determine whether it is the current default browser - or is that GNOME/KDE-dependent as well?
I recently ran into this problem using the standard .tar.bz2 file downloadable from http://download.mozilla.org/?product=thunderbird-3.0.4&os=linux&lang=de

I'm using KDE4 and I wanted to have URLs opened in opera (which I set as my default browser in KDE). However, TB drove me mad because no matter what I did - I couldn't get it from opening URLs in Firefox. No network-protocol handler (in user.js) could fix this. I already suspected some config file outside of KDE to be responsible for that when I read that it is the GNOME default browser setting which causes this behaviour. TB found a default browser for GNOME, so it thought it should use this setting (even though I'm running KDE), and so it doesn't even offer an option to configure which browser is used as a default.

This behaviour is very bad because it is absolutely not intuitive how to resolve this issue if you don't have special knowledge about GNOME (I had to install gnome-editor and disable the desktop>gnome>url-handlers>http. Only then would TB let me select the browser I want to use).

So I totally agree with comment #60 and want to extend this statement to: no matter if TB thinks it knows which browser should be used or not: definitely, there /should/ be an option to choose the browser to use from the start - maybe the http entry in the preferences>attachment section (just like it is *after* removing the GNOME default browser and TB let me choose the browser) should be there per default (since it is not at all obvious how to get this entry if it's not already there). I wouldn't really care then, if it chose the GNOME default browser as long as I can change that. 
Of course, then, if one decides to /change/ the default browser when running GNOME, this had to be changed manually in the http entry. So I understand that handling of all different cases (different desktop environments/window managers) is not a trivial task, but for starters, in my opinion either the two major DEs (GNOME and KDE) should be considered, or the browser to use should have to be set manually (possibly with some default options to choose like firefox, opera, konqueror, chrome etc.).
no activity for a long time, should be closed
Summary: URL not opened → URL not opened on Linux
This happens to me on Ubuntu. I'm running system Firefox started from the Ubuntu unity desktop and system Thunderbird started from the command line. I choose a profile in both Firefox and Thunderbird.

Clicking (or right-clicking and choosing Open Link in Browser) an http link in Thunderbird does nothing. No output in the console where I started TB.

Everything else works:
Entering `xdg-open http://example.com` opens a new Firefox tab (so long as I started FF from the desktop).
Entering `firefox http://example.com` opens in a new Firefox tab
Double-clicking html files in the Ubuntu Files viewer opens in a new Firefox tab
If a message has file.html attached and I click Thunderbird's "1 attachment: file.html", it offers Open with [Firefox Web Browser (default)] and clicking [OK] opens in a new Firefox tab.

In Edit > Preferences > Attachments > Incoming, http and https are grayed out and both show "Use Firefox Web Browser (default)".

^This last makes no sense, it seems to be the same choice that the attachment menu offers. Why does one work and not the other?

As a workaround, in Edit > Preferences > Attachments > Incoming I changed http and https to always ask, and choose Firefox each time.
But then I switched them back to "Use Firefox Web Browser (default)" and now the links open in Firefox. I have no idea what that changed.

(In reply to Thommie Rother from comment #79)
> no activity for a long time, should be closed
No way. A steady trickle of TB and Firefox users have this problem. I found http://codeverge.com/mozilla.support.thunderbird/clicking-a-link-in-thunderbird-wo/1521382 from 2012.
Is comment 78/comment 60 a valid approach?

Or is this rather a distro/support issue?
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(acelists)
Summary: URL not opened on Linux → Thunderbird seems to not respect the default browser set in Linux Desktop Environment preferences
I don't have much input to this. But the http/https entries in the Thunderbird preferences are not needed (anymore?) AFAIK. If there's a problem I'd clear them and go from there.
Flags: needinfo?(mkmelin+mozilla)

I don't know what to add here. I do not use the KDE4 default browser settings and I do not open links directly from TB. Other programs also do not open the same browser consistently, sometimes it is Seamonkey, sometimes Chrome, sometimes Firefox. This even changes for the same program between OS restarts. It is such a mess I do not rely on it and just copy links to my main open browser.
So I don't know where should TB get the setting from.

Flags: needinfo?(acelists)

(In reply to Magnus Melin [:mkmelin] from comment #82)

I don't have much input to this. But the http/https entries in the
Thunderbird preferences are not needed (anymore?) AFAIK. If there's a
problem I'd clear them and go from there.

Franco, Richard, do you have any thoughts on this?

Severity: normal → S4
Flags: needinfo?(richard.leger)
Flags: needinfo?(francogpellegrini)

(In reply to Wayne Mery (:wsmwk) from comment #84)

(In reply to Magnus Melin [:mkmelin] from comment #82)

I don't have much input to this. But the http/https entries in the
Thunderbird preferences are not needed (anymore?) AFAIK. If there's a
problem I'd clear them and go from there.

Franco, Richard, do you have any thoughts on this?

Wayne, am I the right Richard to ask about this?
Indeed I am not sure what the "http/https entries in the Thunderbird preferences" refers to...

Flags: needinfo?(richard.leger)

Is this still a problem?

Flags: needinfo?(francogpellegrini) → needinfo?(mkmelin+mozilla)

AFAIK it's not.

Status: NEW → RESOLVED
Closed: 4 months ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: