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 attachment 63638 [details] 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ä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.
