Closed
Bug 876412
Opened 12 years ago
Closed 11 years ago
"Firefox is already running" following any link in -no-remote
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 382477
People
(Reporter: realRaven, Unassigned)
References
Details
clicking on any link in Thunderbird (mail, content, content tab) _while_ firefox is running produces 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."
I know this has been flagged invalid before, but I believe it is only since 22beta... Might be a windows configuration issue? A better error message or link to a kb article would be desirable.
Comment 1•12 years ago
|
||
Blake how do you like the idea ?
Axel would you make the patch for that if Blake liked the idea ?
Comment 2•12 years ago
|
||
Is this for 64bit builds only?
Because I can't seem to reproduce using:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Thunderbird/22.0 ID:20130522102634 CSet: b95ad3076d7c
Comment 3•12 years ago
|
||
The fact that I'm commenting here indicates that I can't reproduce this on Mac, either… ;)
I think we need to figure out why this is happening before we try to figure out what to do about it.
| Reporter | ||
Comment 4•12 years ago
|
||
hmm, no this was done with the 32bit build, downloaded from the link you provided. I would agree with Blake, to find out why it is thrown first. Unfortunately I still cannot build Tb otherwise I would be able to debug it. I will try with Venkman, maybe I come to a result.
Writing a patch (that changes the error message) would involve l10n of the new text - how long is the turnaround for landing something like this?
| Reporter | ||
Comment 5•12 years ago
|
||
So unfortunately I do not get very far with Venkmann:
Components.classes["@mozilla.org/uriloader/external-protocol-service;1"]
.getService(Components.interfaces.nsIExternalProtocolService)
.loadUrl(uri);
fails (and issues the error message).
.getService works, and as far as I can see uri is initialized correctly (uri.port=-1, don't know if that one is as expected; host, path & spec look alright). I'd say the loadUrl is handled in C++?
=> my guess:
https://mxr.mozilla.org/comm-central/source/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp#845
so I would need the C++ build to debug it in my VS2010 environment.
| Reporter | ||
Comment 6•12 years ago
|
||
Sorry for the bugspam, Firefox is also 32bit (21.0). However, if I set Internet Explorer as default browser (shucks) it actually works. SO I guess it is probably a Firefox bug, rather than one of Thunderbird - Can you reassign this to Fx?
Comment 7•12 years ago
|
||
I think at least using -no-remote and opening from the second instance reproduce this at least more often.
| Reporter | ||
Comment 8•12 years ago
|
||
More tests on the topic:
1. returning to 17.0.6 with the same profile - all links work as expected, bug not reproducable.
2. starting thunderbird beta in safe mode (all addons disabled) - error shown, as above (Firefox is already running, but is not responding..."
3. tb beta with a fresh profile: clicking KNow your righs - opens a new tab, clicking the link "Mozilla Public LIcense" generates the error
So this is definitely Fx32bit beta-specific, not account specific; Of course it could have to do with settings in my Windows7 user profile as well, so the next test will be with a fresh Win7 profile.
Questions
If there are any other tests regarding this bug you would like me to do please tell?
Could somebody create / attach a diff for relevant changes in nsExternalHelperAppService against 17.0.6? (or tell me how to do it)
| Reporter | ||
Comment 9•12 years ago
|
||
Breakthrough: I am able to make the bug go away by removing the command line switch
" -ProfileManager -no-remote" (which I have on the beta shortcut). So Magnus was right (I didn't consider this as I did not run both versions at the same time). So we can definitely conclude that the bug only happens when the -no-remote switch is employed; The bug is consistent with Tb 17.0.6, if I appened -no-remote to Tb17 it behaves the same.
updating the title to reflect.
demoting to minor importance as it is a minority of use cases
Severity: normal → minor
Summary: "Firefox is already running" Following any link in content + message → "Firefox is already running" following any link in -no-remote
Comment 10•12 years ago
|
||
I don't want to upset anybody, but I have this bug for quite a long time.
I have 2 profiles in TB and 2 profiles in FF. But either firefox runs as "firefox" or "firefox -P default" I face this problem when I click on a link in TB.
Environment:
Linux arch 3.9.6-1-ARCH #1 SMP PREEMPT Fri Jun 14 08:12:55 CEST 2013 x86_64 GNU/Linux
Thunderbird 17.0.6
Mozilla Firefox 21.0
I tried everything I found in mozilla knowledge base, also I wrote a script and set it as the action in TB preferences, but no avail:
#!/bin/bash
firefox -P default -new-tab "$1"
I tried other options, too.
Actually I run out of ideas. I tried getting help on Arch Linux forums as well: https://bbs.archlinux.org/viewtopic.php?id=165378
If you want me to check out something, just tell me. Thanks.
Comment 11•11 years ago
|
||
I just hit this bug trying to run two different instances of thunderbird on the same the box.
TB 24.2.0 on 64bit linux. If I remove the -no-remote or -new-instance flags, things work as expected, except that I then cannot run the second instance with the different profile.
Comment 12•11 years ago
|
||
The cause of this bug is the MOZ_NO_REMOTE environment variable.
When you launch Thunderbird with the -no-remote flag it goes and sets this variable for you. When you click on a link and Thunderbird execs a copy of Firefox that env variable is inherited by the Firefox process. Firefox then attempts to load the default profile a second time, fails, and give the nebulous "Firefox is already running" warning dialogue.
The solution would be to either unset the env variable before firefox is executed, or not set the variable at all when the command-line flag is used.
In the meantime, I've posted a stopgap solution to: http://forums.mozillazine.org/viewtopic.php?f=39&t=2800511
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•