480709 - application preferences aren't respected if network.protocol-handler prefs are set (e.g. can't open links in e-mails)

Status: RESOLVED DUPLICATE of bug 389732

(Core Graveyard :: File Handling, defect)

Description

[my-bugzilla]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090226 Shredder/3.0b3pre

Hello,

I can't open links out of e-mails with Firefox 3.0.6.

about:config looks like that:
   network.protocol-handler.app.http;/usr/bin/firefox
   network.protocol-handler.app.https;/usr/bin/firefox

Best regards

PS: That's my first bug report and my English isn't very good... ;-)

Reproducible: Always

Steps to Reproduce:
1. Receive an e-mail with a link
2. Try to open it with your browser (e.g. Firefox)
Actual Results:  
nothing

Expected Results:  
open the link with Firefox ( /usr/bin/firefox )

Comment 1

[my-bugzilla]

It also affects all the other links in Thunderbird (not only the links in e-mails) e.g. 

"Help > Version Information" 
    (I don't know, whether this is the correct name because I run the German version: "Versionshinweise")
"Extras > Add-ons > Download Add-ons > Show all Add-ons"
    (German: Extras > Add-ons > Add-ons herunterladen > Alle Add-ons ansehen)

Comment 2

[Ludovic Hirlimann [:Usul]]

Can you try to reproduce in safe-more (with -safe-mode argument on the command line) ?

Any messages in the Error console ?

Comment 3

[Magnus Melin [:mkmelin]]

You shouldn't need those prefs. 
Just remove them, set firefox as your default browser and you should be good to go.

Comment 4

[Kevin Kempfer]

I can confirm this behavior on Ubuntu 9.04, Thunderbird 2.0.0.0 (20070326) with both network.protocol-handler.app.http set and unset.

There are no messages in the Error console.

Running Thunderbird from the console in safe mode prints out a message when clicking on a hyperlink:

Couldn't load XPCOM.

Comment 5

[Magnus Melin [:mkmelin]]

Don't know about the original report, but Kevin, your issue might be bug 489080.

Comment 6

[Bob Vincent]

Confirmed on Thunderbird 2.0.0.22, Ubuntu Jaunty.

I'm not running Gnome nor KDE, but I am running dbus and hal.

Relevant portions of my prefs.js file are:

user_pref("network.protocol-handler.app.ftp", "/usr/bin/firefox");
user_pref("network.protocol-handler.app.http", "/usr/bin/firefox");
user_pref("network.protocol-handler.app.https", "/usr/bin/firefox");
user_pref("network.protocol-handler.expose-all", true);
user_pref("network.protocol-handler.expose.http", true);
user_pref("network.protocol-handler.expose.https", true);
user_pref("network.protocol-handler.external.ftp", true);
user_pref("network.protocol-handler.external.http", true);
user_pref("network.protocol-handler.external.https", true);
user_pref("network.protocol-handler.warn-external-default", false);

Comment 7

[Ludovic Hirlimann [:Usul]]

(In reply to comment #5)
> Don't know about the original report, but Kevin, your issue might be bug
> 489080.

Kevin can you answer that please ? Bob is bug 489080 corresponding to what you are seeing ?

Comment 8

[Bob Vincent]

Sorry; I was reporting on 2.0.0.22 and this report seems to involve the 3.0 betas.

With Thunderbird 3.0b3pre, the problem seems to be resolved, at least for me.

I have responded to bug 489080 separately.

Comment 10

[Ludovic Hirlimann [:Usul]]

Erwann do you see anything in Tools-> Error console ? Anything in the system's syslog ?

Comment 11

[Wolfgang Rosenauer [:wolfiR]]

network.protocol-handler.app.* prefs are obsolete starting with Gecko 1.9 IIRC.
In a Linux/Gnome environment the first shot is to ask gconf for the http url-handler and invokes whatever is specified there.
wolfi@Hygiea:~> gconftool-2 -g /desktop/gnome/url-handlers/http/command
firefox %s

Comment 12

[Erwan David]

Nothing in system logs
In error console I get (in safe-mode) a message
Failed to load XPCOM component:
/opt/edavid/thunderbird/components/libmozgnome.so

then a warning 
Warning: Timed textboxes are deprecated. Consider using type="search" instead.
Source File: chrome://messenger/content/messenger.xul
Line: 0

But those are written at startup before I try any link.
/opt/edavid/thunderbird/components/libmozgnome.so is here

ls -l /opt/edavid/thunderbird/components/libmozgnome.so
-rwxr-xr-x 1 edavid edavid 32776 Jul 15 23:34
/opt/edavid/thunderbird/components/libmozgnome.so

As I said before there is no gnome nor KDE on this machine

Comment 13

[Erwan David]

Wolfgang: Not everybody is running gnome, or willing to install it. gconf is very complicated to handle outside a full gnome environment that some people (including me) find particularly complicated and cumbersome.

It seems to me that having a split configuration between thunderbird's one and an external software is bad practice and will lead to problem.

Comment 14

[Wolfgang Rosenauer [:wolfiR]]

I don't pretend that everyone needs to run Gnome. I don't run it myself but I have the Gnome infrastructure (as gconf) installed and that is expected from Thunderbird (or Firefox). Although the design is to not break completely but libmozgnome.so cannot be loaded due to missing dependencies. The question is what actually happens in that case or even what is supposed to happen in that case.
In the past the prefs were used but I'm not completely sure how the current implementation handles them. That is probably broken by intention or accident.

Comment 15

[Erwan David]

(In reply to comment #14)
> I don't pretend that everyone needs to run Gnome. I don't run it myself but I
> have the Gnome infrastructure (as gconf) installed and that is expected from
> Thunderbird (or Firefox). Although the design is to not break completely but
> libmozgnome.so cannot be loaded due to missing dependencies. The question is
> what actually happens in that case or even what is supposed to happen in that
> case.

gnome is huge, On my debian it leads to
Need to get 304MB of archives. After unpacking 824MB will be used. Too big for some people

> In the past the prefs were used but I'm not completely sure how the current
> implementation handles them. That is probably broken by intention or accident.

If by intention, then it should be advertised, allowing to choose knowingly (and to change email client if prefered). If by accident, then here is the place to signal it...

Comment 16

[Wolfgang Rosenauer [:wolfiR]]

From looking a bit at the code it should still work.
There is a bit of logging available from TB for that case:
export NSPR_LOG_MODULES="HelperAppService:5"
before you start TB from a console and watch for the output if you click on an http/https link.

I got something like:
1026582496[7f3a33312040]: -- nsOSHelperAppService::OSProtocolHandlerExists for 'https'
1026582496[7f3a33312040]:    found app /usr/bin/firefox
1026582496[7f3a33312040]:    handler exists: yes
1026582496[7f3a33312040]:    found app /usr/bin/firefox

Comment 17

[Erwan David]

(In reply to comment #16)
> From looking a bit at the code it should still work.
> There is a bit of logging available from TB for that case:
> export NSPR_LOG_MODULES="HelperAppService:5"
> before you start TB from a console and watch for the output if you click on an
> http/https link.

Ok, it seems my problem is different. Here is what I get:
-1227830400[b6a11060]: -- nsOSHelperAppService::OSProtocolHandlerExists for 'http'
-1227830400[b6a11060]:    found app /home/edavid/bin/firefox
-1227830400[b6a11060]:    handler exists: yes
-1227830400[b6a11060]:    found app /home/edavid/bin/firefox

Then firefox does not start.

I tried putting a wrapper to see the parameters (a mere acho then exec firefox) : the wrapper is not called.

Comment 18

[Erwan David]

(In reply to comment #17)

I found a way to get back the functionnality :

1) Remove the user_pref("network.protocol-handler.app.http",firefox) from user.js and pref.js

2) thunderbird then asks for the application to use.

It is now managed like attachments.

3) it works

Same for https of course.

Comment 19

[Wolfgang Rosenauer [:wolfiR]]

That is a workaround indeed but it's pretty inconsistent. The "backend" as in uriloader/exthandler still supports network.protocol-handler.app.* happily (and prefers it even above Gnome interfaces (e.g. nsGnomeRegistry)) but somewhere in the "frontend" it's not used in the end. It blocks the application chooser though and that suggests again that the pref is supposed to be honored.

I think this bug should be moved to whatever component uriloader/exthandler is as it's not special to Thunderbird.

I've just tested with Firefox and got the following result:
- set network.protocol-handler.app.mailto=/usr/bin/kmail
- verify that kmail is shown in the Applications pref for mailto (correct)
- click on a mailto link
- thunderbird's composer comes up (quite wrong as even FF's UI shows to use   
  kmail beforehand)

Comment 20

[Magnus Melin [:mkmelin]]

Updating summary.

Comment 21

[Wolfgang Rosenauer [:wolfiR]]

I dupe that as the fix is in the other bug. (Actually I fixed that a long time ago and forgot about it :-()

The fix is really that network.protocol-handler.app.* prefs are not supported/used anymore. It wasn't removed completely and caused the UI issues.