User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170613225334 Steps to reproduce: Devuan 1.0 with latest updates. System is run as a VM under Virtualbox 5.1.24 and 5.1.26; amd64 running 1 vcpu. XFCE desktop; Xorg 1:7.7+7. BTW, I tried this before and after updating to the recent update, Tbird 52.2.1. Started a firefox session: /usr/lib/firefox-esr/firefox-esr -ProfileManager -new-instance and selected "prof1"; also frequently have another session running as "prof2" I created a bash script: #!/bin/bash /usr/bin/firefox -P prof1 -new-tab $1 If I invoke script with, say, "cnn.com", from the command line, it works correctly, opening a new tab next to the other open tabs and loads the cnn web site without problems. But if I try to open an http link from Thunderbird, and select my script to run, I get this error: Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system. Actual results: I get the error "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system." While opening a link from Tbird, I tried "tracing" my script and captured the env(1) output and the literal string generated after expansion of $1 to an external file. I ran that external file from the command line (passing it to sh(1)) and it ran precisely as my script did previously from the command line. As I'd really like to make this work properly, I am happy to provide more info and work with you to get this addressed (if it is technically possible, and it seems like it should be). I understand that I could, as an alternative, run multiple instances of TB and FF under separate logins, but that would mean a lot more overhead. I simply want to run multiple instances, one per XFCE "desktop", as switching back and forth this way is easy and fast and should use fewer resources than the separate logins approach. Your help is greatly appreciated. Expected results: I expected (perhaps wrongly) that the script I wrote would work flawlessly as it does from the command line.
Yes, this is the never-ending story of "no-remote", also called "new-instance". Looks like a dupe of bug 382477, Wayne?
indeed it is. when in doubt, the list of duplicates is helpful in determining the range of issues covered
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 382477
Duplicate? Related, possible; not sure if this is purely "duplicate" -- but that might depend on your response to this post. Recall that the mechanism DOES, indeed, work if the target program, firefox, is called from a shell script (or command line directly, either way), but not when the exact same script is called from WITHIN thunderbird. I conclude from this sort of accidental "experiment" that the real problem is in how the call is invoked, not the particular arguments to the call. If the issue were the particular arguments being used to call the target program, then I'd expect these to fail consistently. But they don't, given I can successfully make firefox do what I want it to do via the command line. It must be something having to do with the environment or mechanism that is used to fire off the call to open the new tab in the target. Therefore, while possible related somehow, this bug report does not sound quite like the scenario(s) described in the other bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
BTW, it seems that -no-remote and -new-instance are somewhat different. While they both start sessions of firefox independent of running ones, -no-remote supposedly is insulated from external calls, such as attempts to open new windows and tabs from outside the instance (e.g., my script). Having tested a bit with this, I can confirm that these options do, in fact, have said distinctions.
Yes, they are slightly different https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-new-instance but highly related
I agree totally with you in re the -new-instance and -no-remote options. The -no-remote is like -new-instance but with the added ability to sort of "ignore" remote commands -- my own scenario is an example of where I needed to use -new-instance rather than -no-remote; the latter simply would not work (even from command line), but the former does work (at least from the command line). However, the nature of the problem I'm reporting appears to be due to the environment in which the ff command (with the -new-tab and -profile switches) is launched from, since I am able to make the combination of options work from the command line (or inside a script) but not as a binding for http/https attachments from within tbird. I thin we can safely say that this is not a duplicate of the other bug(s). Thanks again.
Being I've gotten so curious about the cause of this, and having looked at the dependency 382477 (as per Jorg in comment #4), I thought I'd try a little more to find out why and how this occurs. I played with a variety of variables I could see from running env(1) to a /tmp file (from inside the script) and examining the differences between environments in the command line invocation versus the thunderbird invocation. So now my script looks thus: #!/bin/bash #export MOZ_LAUNCHED_CHILD=17490 #XRE_PROFILE_NAME=prof1 #export NO_MOZ_REMOTE=0 #export MOZ_NEW_INSTANCE=0 unset MOZ_NEW_INSTANCE env | sort > /tmp/junk #/usr/bin/apulse /usr/bin/firefox -P prof1 -new-tab $1 /usr/bin/firefox -P prof1 -new-tab $1 As you can see, I fiddled with a few envars, turning them on or off, both individually and in combination. I noticed that MOZ_NEW_INSTANCE didn't seem to make any difference whether it is set to 0 or 1, so I went ahead and unset it altogether. Now I get the expected behavior. The code that checks for the value of MOZ_NEW_INSTANCE is probably the cause of this issue. I have not examined the code, so I don't know exactly where or how this is occurring, but it should get devs a bit closer to a resolution. At very least, I hope my testing and experimentation has been helpful and useful to you all. Please let me know if there are any further tests you would like me to try, before or after updates to mozilla code.
Actually, what led me to unset the MOZ_NEW_INSTANCE variable was the fact it doesn't even show up in the envars for the command line invocation. But this ought to be a big clue to the solution.
other bugs https://mzl.la/2xi5q0W
You need to log in before you can comment on or make changes to this bug.