Bugzilla Bug 99084

I have the line user_pref("network.protocol-handler.app.http",
"/usr/bin/firefox"); in my prefs.js for thunderbird and in 1.0.2 it would open
clicked http urls just fine.  But it no longer works in 1.0.5 when thunderbird
is launched from /usr/bin/thunderbird.  If i call thunderbird directly as
/usr/lib/thunderbird/thunderbird-bin it DOES work though.

Reproducible: Always
Steps to Reproduce:
1. put http handler in prefs.js
2. launch thunderbird from /usr/bin/thunderbird
3. click http link

Actual Results:  
Nothing happens

Expected Results:  
Firefox should launch

I also just started experiencing this problem with thunderbird 1.0.5.  Running
/usr/bin/thunderbird breaks link forwarding to firebird-- the terminal window
shows a message:
/usr/libexec/mozilla-launcher: can't find the browser :-(

However, if I run /usr/lib/thunderbird/thunderbird-bin, link forwarding to
firebird works again.  Anyone have any ideas?

what version of mozilla-launcher do you currently have installed? The problem
looks like the link from mozilla-launcher to thunderbird-bin has not been
completed properly.

I have mozilla-launcher version 1.35 installed. (>=1.34 was required just to
install thunderbird 1.0.5).

/usr/bin/thunderbird is a stub script calling /usr/libexec/mozilla-launcher
(as is /usr/bin/firefox)

[ebuild   R   ] www-client/mozilla-launcher-1.35  6 kB

I also get the same error with mozilla-launcher-1.34.

I am still unable to duplicate the problem .. I do not include nothing in my
prefs.js either and it works fine.

What do you mean you don't include anything in your prefs.js?  If there's
nothing in there, how do you open links in firefox?

user_pref("network.protocol-handler.app.http", "/usr/bin/firefox"); Is what
some
of you all have been including to get your browser to open when  you click a
url.  I however do not include this at all my prefs.js is the default that are
set on initial install and setup for user activity.

I just removed the line and restarted thunderbird and clicking links, nothing
happens.  Nor do I get any output in the window i started thunderbird.

Yeah, me too.  Without the needed lines in prefs.js, I don't get a web browser
to open, nor do I get any error message, when I click on a link.  Jory, are you
saying you can get links in thunderbird to open in a web browser without these
lines in prefs.js? I don't understand how.

Ryan yes I am saying mine work without adding nothing to the prefs.js for web
browsing functions ... I just opened the bug report while clicking the link in
thunderbird ... please re-emerge mozilla-launcher test it if that does not work
go ahead and add the lines back and test it then. Please report back with
success or failure.

Two Lines you might want/need to add are:
pref("network.protocol-handler.app.http","/usr/bin/firefox");
pref("network.protocol-handler.app.https","/usr/bin/firefox");

*** Bug 99157 has been marked as a duplicate of this bug. ***

I reemerged mozilla-launcher and it does not work with or without the lines.

I've added this line:

export MOZILLA_LIBDIR=/usr/lib/MozillaFirefox/

to /usr/bin/firefox and it works.

Explanation:
launching /usr/bin/thunderbird{-bin,} exports MOZILLA_LIBDIR, and when link is
clicked in TB the variable is inherited by /usr/bin/firefox, and
mozilla-launcher tries to run /usr/lib/thunderbird/firefox-bin.

Confirmed it works by adding that line to firefox's script.  Still need the
lines in the .js file tho.  I don't understand how it works for Jory though.

That kinda makes sense to me.  I noticed earlier that the exporting of the
MOZILLA_LIBDIR variable was the only difference between the thunderbird and
firefox stub scripts.  Anyone have any idea why the firefox script doesn't
contain the line? Or when the line was added to the thunderbird script? 
Otherwise, I still don't quite understand how updating thunderbird exposes a
problem with firefox.

Anyhow, good find.  This fixes it for me.  What package actually contains the
/usr/bin/firefox stub script?

And yes, I too need the lines in the prefs.js, but that doesn't really bother me.

(In reply to comment #16)
> That kinda makes sense to me.  I noticed earlier that the exporting of the
> MOZILLA_LIBDIR variable was the only difference between the thunderbird and
> firefox stub scripts.  Anyone have any idea why the firefox script doesn't
> contain the line? Or when the line was added to the thunderbird script? 
> Otherwise, I still don't quite understand how updating thunderbird exposes a
> problem with firefox.

It's a problem with firefox's stud script, not with thunderbird.

> Anyhow, good find.  This fixes it for me.  What package actually contains the
> /usr/bin/firefox stub script?

firefox

> And yes, I too need the lines in the prefs.js, but that doesn't really bother me.

I have them too.

I am not commiting this fix to portage this is not the cause it is a simple
work
around ... a handful of you only are having the issue not everyone as kryzysiek
is suggesting. On the other hand yes there is a problem and when I narrow it
down all the way I will take and comment on the fix and add it to the tree.

Jory, I belive that the problem is because since the LIBDIR gets exported in
the
thunderbird script, when thunderbird calls the firefox launcher, the exported
variable carries over.  the mozilla-launcher sees that it is exported and
doesn't make it point to the correct firefox dir.  Fixing the mozilla-launcher
to take the new thunderbird dir into account should fix it.

As I stated earlier this would effect all users not just a handful of you all
... the issue is deeper then the export just be patient and we will get it
straightened out.

Out of curiosity, do you know why the thunderbird needs the LIBDIR export and
firefox (supposedly) does not?

if you look at mozilla-launcher you can see it technically does not need it,
when coding thunderbird ebuild it was easier to use a install sub function which
is reason behind it ... firefox can not use same method seeing the /usr/lib(64)
is MozillaFirefox. Hope that helps ya understand a bit better, also the export
on the LIBSDIR is exported in mozilla-launcher.

Well, my copy of thunderbird needs the LIBDIR export in the stub script.  If I
comment out the export, the wrapper complains it can't find thunderbird.  This
failure is because without the export, it looks for the thunderbird binary in:
/usr/lib/MozillaThunderbird
which does not contain the binary, it is actually located in /usr/lib/thunderbird.

However with the LIBDIR export in place in the thunderbird script, and NOT
included in the firefox script, mozilla-launcher looks for the firefox binary as
/usr/lib/thunderbird/firefox-bin (when exectuted from thunderbird).  It appears
that the LIBDIR exported by the thunderbird script is not ever reset to properly
execute firefox.

finally on a clean install I have been able to duplicate this particular bug. I
will be working a fix asap!!

I am also experiencing this problem. When I first upgraded it worked sometimes
and then as someone on #gentoo suggested I did emerge -C thunderbird and emerge
thunderbird. After doing that I have never been able to click links. 

Side note: I use user.js to set the preferences. prefs.js can get overwritten as
far as I understand it. 

From mozilla-launcher:
which_browser() {
  # Newer launcher stubs will set MOZILLA_LIBDIR so that the installation
  # location is controlled by the ebuild rather than mozilla-launcher, finally!
  if [[ -n $MOZILLA_LIBDIR && -d $MOZILLA_LIBDIR ]]; then
    export MOZILLA_FIVE_HOME=$MOZILLA_LIBDIR
  else
    export MOZILLA_FIVE_HOME='' # set below
  fi

So it is clear the the value from the thunderbird stub is used. The firefox stub
will need to be corrected by adding 
export MOZILLA_LIBDIR=/usr/lib/MozillaFirefox or some unrecommended checking to
the mozilla-launcher script

FYI - I fixed it by:

---  usr/libexec/mozilla-launcher
+++ usr/libexec/mozilla-launcher
@@ -182,6 +182,7 @@
   case $zero in
     *fox-bin)
       : ${MOZILLA_FIVE_HOME:="/opt/firefox"}
+      MOZILLA_FIVE_HOME="/opt/firefox"
       remote=$MOZILLA_FIVE_HOME/mozilla-xremote-client
       mozbin=$MOZILLA_FIVE_HOME/firefox-bin
       grepfor=Firefox-bin

Obviously this only fixes it for firefox-bin, and doesn't allow the path to be
overriden.  Putting an export in the firefox-bin stub script might be a better
solution.

However, I figured tossing out alternatives wouldn't hurt.

aight after much research I have found out why I was and once again able to
click links in firefox without adding them 2 lines to prefs.js and without
modifing /usr/bin/firefox :D The answer is easy I set firefox as the default
browser, this can be accomplished by editing your preferences it is under
general just set firefox as default browser and problem solved.

links in TB not firefox but you get the point I hope.

Changing the default browser did not help me.

I attached a new firefox-bin ebuild which sets the LIBDIR.  Since this seems to
be the direction that mozilla-launcher is taking, would it make sense to just
patch the stub in this manner and then not worry about defaults and fixing
LIBDIR in the launcher/etc?

Created an attachment (id=63638) [edit]
ebuild for firefox-bin which fixes the LIBDIR problem

(In reply to comment #28)
> aight after much research I have found out why I was and once again able to
> click links in firefox without adding them 2 lines to prefs.js and without
> modifing /usr/bin/firefox :D The answer is easy I set firefox as the default
> browser, this can be accomplished by editing your preferences it is under
> general just set firefox as default browser and problem solved.

Why can't I find an option in thunderbird or firefox to set the default browser?
(Both are version 1.0.5)

Seeing as how thunderbird exports LIBDIR now, and setting prefs.js to use
/usr/bin/firefox to open links is a VALID way to set things up, I think fixing
the /usrbin/firefox script is a necessary fix.

I can't find the default browser setting either.  But why not just fix the
mozilla-launcher with the new thunderbird path so no one needs to set LIBDIR
anywhere?  It's worked like that up until now.

Fixin a stub for something that is not busted is not the answer. If you set the
default browser in firefox which is under general settings in preferences you
would be done already ... the fix your wanting is nothing more then a bunch of
wash it clears the export of thunderbird when mozilla-launcher is executed.

(In reply to comment #34)
> Fixin a stub for something that is not busted is not the answer. If you set the
> default browser in firefox which is under general settings in preferences you
> would be done already ... the fix your wanting is nothing more then a bunch of
> wash it clears the export of thunderbird when mozilla-launcher is executed.

Uh, I don't see any such choice in the general preferences screen?  I can attach
a screen-shot if that would help.

The mozilla-launcher.eclass ends with:

#!/bin/sh
#
# Stub script to run mozilla-launcher.  We used to use a symlink here
# but OOo brokenness makes it necessary to use a stub instead:
# http://bugs.gentoo.org/show_bug.cgi?id=78890

export MOZILLA_LAUNCHER=${name}
export MOZILLA_LIBDIR=${libdir}
exec /usr/libexec/mozilla-launcher "\$@"
EOF
        chmod 0755 ${D}/usr/bin/${name}
}

So, all that is really proposed is setting up the firefox stub in the same
manner that the eclass will.  

In going through the mozilla-launcher code it seems that MOZILLA_LIBDIR is taken
from the environment and used to set the location from which firefox is
launched.  While some testing clearly shows the script is trying to launch
firefox (as it has cleared MOZILLA_LAUNCHER), it is looking for it in the
thunderbird directory (as it has NOT cleared MOZILLA_LIBDIR).

I think that putting LIBDIR in the stub is an elegant solution since it gets
around all the hard-coding of paths for 14 different applications in a single
script.

(In reply to comment #35)
> I think that putting LIBDIR in the stub is an elegant solution since it gets
> around all the hard-coding of paths for 14 different applications in a single
> script.

Exactly my point - it's the most elegant (and IMHO logical) solution.

But I don't have such an option.  Under firefox preferences, in the General
section, I have:
Home Page
Fonts & Colors
Languages
Connection

No default browser to be found.  This includes if I blow away my profile and
start firefox with no profile at all.

Also, why then do the comments in the mozilla-launcher script seem to indicate
that exporting LIBDIR is the way of the future:
"Newer launcher stubs will set MOZILLA_LIBDIR so taht the installation location
is controlled by the ebuild rather than mozilla-launcher, finally!"

(In reply to comment #34)
> Fixin a stub for something that is not busted is not the answer. If you set the
> default browser in firefox which is under general settings in preferences you
> would be done already ... the fix your wanting is nothing more then a bunch of
> wash it clears the export of thunderbird when mozilla-launcher is executed.

This is not Windows. I am running kde. I don't know if this will show up in
Gnome but I doubt it.  

Petteri R

Petteri Räty if you want to be a wiseass do it elsewhere I do not have time for
this non-sence. If you can not see for yourself maybe you can see in this
screenshot, http://dev.gentoo.org/~anarchy/images/firefox-prefs.jpg hopefully
you r not as arrogant as your last post when you see fluxbox as the windows manager.

(In reply to comment #39)
> Petteri R

(In reply to comment #39)
> Petteri Räty if you want to be a wiseass do it elsewhere I do not have time for
> this non-sence. If you can not see for yourself maybe you can see in this
> screenshot, http://dev.gentoo.org/~anarchy/images/firefox-prefs.jpg hopefully
> you r not as arrogant as your last post when you see fluxbox as the windows
manager.

Well, I wouldn't have believed it if I didn't see it myself.  I would love to
know why I don't have any such option.  Or better yet, I would love to know what
the linux standard is for this since I've never seen any such way.

However, I still don't see it as a problem to fix the firefox stub script.  I
don't consider it a hack to add the LIBDIR export, but merely making firefox
reflect the way things are going in the future and making it compatable with
thunderbird.  Just because you can use firefox to set it as the default browser
doesn't mean you can't be able to override it with thunderbird's settings.  What
if I set some other browser as default and want to use firefox to open links in
thunderbird?  Opening links in _thunderbird_ should not depend on a setting in
_firefox_.

Jory, after a quick poll on IRC, aparently the gnome use flag is what puts that
there.  So not everyone has it.  I know I don't, and I'd show you the screenshot
but its 200k and I have no where to put it.

(In reply to comment #39)
> Petteri R

(In reply to comment #39)
> Petteri Räty if you want to be a wiseass do it elsewhere I do not have time for
> this non-sence. If you can not see for yourself maybe you can see in this
> screenshot, http://dev.gentoo.org/~anarchy/images/firefox-prefs.jpg hopefully
> you r not as arrogant as your last post when you see fluxbox as the windows
manager.

Sorry, if I was rude. I maybe should have looked more closely into who I am
talking to. I was just a little pissed off by the trouble this bug has caused
(and klipper when you have to through the clipboard). Should take more time to
cool myself down. It doesn't change the fact that I have never seen this
preference on this Linux before (I even have the gnome use flag on). It's good
to know that it is possible. It would be best to have this bug fixed as soon as
possible as it is starting to repeat itself. 

Ok, I fixed up a number of things that will affect this bug:

1. I marked mozilla-launcher-1.35 stable, which includes a workaround for
systems that have a mix of symlinks and stubs in /usr/bin

2. I updated to mozilla-firefox-1.0.5-r1, mozilla-thunderbird-bin-1.0.5-r1,
mozilla-firefox-bin-1.0.5-r1 which depend on the newer mozilla-launcher, plus
they install using the eclass function instead of directly in the ebuild

Please re-open this bug if you still have problems after updating.

(In reply to comment #43)
> Ok, I fixed up a number of things that will affect this bug:

> they install using the eclass function instead of directly in the ebuild
> 

Thanks - that works great here...

I don't think that this bug affects galeon users much, if at all.

It was not a good idea to remove mozilla-firefox-1.0.5.ebuild from the tree as
it's more difficult to mask this revision now.

 

The revision is in the tree and set for ~arch testing. 1.0.5-r1 just fixes the
stubb reason it was marked as stable.

Ok. Let me but it this way:

I'm generally only using *Galeon* compiled against firefox so it didn't make
sense for me to upgrade from 1.0.5 to 1.0.5-r1, as this bug doesn't concern me
(or other galeon/epiphany users).

The problem was that 1.0.5 was removed right away from the portage tree, so I
couldn't prevent the upgrade showing up with 'emerge -upv world' *simply* by
adding 1.0.5-r1 to my package.mask file.

(These things matter because firefox is a big package to compile for no good
reason, and I don't have amd64 ;)

Oh well, 1.0.6 is out. Maybe it is a better reason to upgrade.