mozilla-launcher-1.11 won't launch firefox if thunderbird 0.6 is running and firefox isn't already running. The script says "Browser doesn't understand command." Clearly, the script is trying to send a "new window" command to Thunderbird instead of realizing that it's not a browser and should be starting up a new browser instance, instead. The script is spagettii code (why isn't it in Python?), so I can't debug it. Reproducible: Always Steps to Reproduce:
Guess what! Users running ~x86 are expected to make an attempt at debugging. You can switch to x86 if you don't want to help out. Regarding the bug, I have a guess what the problem is. If you would run the following and create an attachment to this bug with the output file, I would appreciate it. bash -x /usr/bin/firefox http://google.com/ &>debugging.out
essentially the same thing occurs if you try to start mozilla while thunderbird is running, and it occurs with thunderbird 0.5 (keyword x86) (and no mozilla-launcher installed on the system) as well as 0.6-r1. when you try to start mozilla, thunderbird pops up an alert with the following message: Error launching browser window:TypeError: Components.classes['@mozilla.org/appshell/component/browser/instance;1'] has no properties (i have mozilla 1.6-r1)
Created attachment 32719 [details] Requested bash -x output Attached output of requested command. Other notes: 1. I don't have this problem on a single user system with exactly the same versions 2. This log/problem is from a terminal server with many users on at any given time. 3. We haven't had any trouble with this in the past. 4. No, ~x86 users are expected to make bug reports and provide debugging /information/. I am not a bash+sed+awk programmer and have little or no desire to learn those systems. I have little understanding of what's going on here because of the gratuitous use of $: $@ and the like. I just can't help you write the fix and that's the way it is, sorry. It would be silly to expect all ~x86 users to be versed in all of the programming languages in use around the system. 5. comment #2 You should file another bug since mozilla's start script is an entirely different matter; there are similarities but the mozilla start script is different than mozilla launcher and requests to fix that should be routed to the appropriate maintainer.
Any ideas?
Jason, thanks for the debugging output. It's clear now what is happening. It's also clear that it isn't easy to fix. Here is the problem: The mozilla-xremote-client distributed with current versions of mozilla, firefox and thunderbird does not have the ability to distinguish between the programs. Furthermore, it returns a successful exit status even when the targetted program can't handle the command, for example thunderbird trying to open a new firefox window. The mozilla-launcher script uses some gymnastics to make things work. It does the window search itself and modifies some X properties so that the right window can be targetted. This is a bit slower on local displays, but it's better than not working at all. The associated routines in mozilla-launcher are fake_user and unfake_user. The fake_user stuff is only used if [[ $DISPLAY == :* ]] because we found that it takes prohibitively long (3 minutes or so) to run over a network due to the amount of data that is piped around. Unfortunately xwininfo and xprop are too primitive to do better window selection, so piping the data back and looking through it seems to be the only way. :-( This is also true when [[ $DISPLAY == localhost:* ]] because that indicates (most likely) a remote display being routed through ssh. The fact that you haven't seen this before indicates, most likely, one of the following: (1) It happened to be targetting the right window. This seems to be random. (2) You weren't previously running both firefox and thunderbird simultaenously. (3) You have only tested on local displays in the past. There is a light at the end of the tunnel! The mozilla-1.7 release candidates support a -a programname option which specifies the program to target for mozilla-xremote-client. That means that the next versions of mozilla, firefox, thunderbird, etc. will all support the -a syntax. This is auto-detected by mozilla-launcher so will be used immediately once it becomes available. At the moment, though, I don't have a bug fix for you. I am considering pulling the xremote sources from mozilla's release candidate and patching firefox and thunderbird to bring them up to snuff, since we don't have any idea when there will be new versions released from mozilla.org. That would be a fix but would be ~arch only for the moment. I'll also commit a version of mozilla-launcher that provides a workaround via environment variable. If you specify MOZILLA_FORCE_FAKE_USER=1 then it will use the fake_user stuff even over the network. However I think you will find it to be too slow for real use. That will be in version 1.12 which I will commit soon. Regarding our numbered list: > 1. I don't have this problem on a single user system with exactly > the same versions Right, I would expect that based on the explanation above. > 2. This log/problem is from a terminal server with many users on at > any given time. And this is why it is happening ;-) > 3. We haven't had any trouble with this in the past. That is quite surprising to me. Do you have any ideas why? > 4. No, ~x86 users are expected to make bug reports and provide > debugging /information/. Right, and thank you for doing so. My apologies for the poor reaction. I was just put off by the tone of your initial report. > 5. comment #2 You should file another bug since mozilla's start > script is an entirely different matter; there are similarities but > the mozilla start script is different than mozilla launcher and > requests to fix that should be routed to the appropriate maintainer. That is correct.
Ok, mozilla-launcher-1.12 is committed to portage. It understands MOZ_FORCE_FAKE_USER=1, though I really don't think that is a workable solution. I will look into patching mozilla-xremote-client in thunderbird and firefox.
I'm not going to bother backporting the mozilla-xremote-client changes to firefox/thunderbird since firefox-0.9 just came out. Hopefully there will eventually be a version of thunderbird with similar changes. Unless you want to go through the work of producing the appropriate patch for thunderbird, MOZ_FORCE_FAKE_USER will have to be sufficient for you.
