Closed Bug 427206 Opened 16 years ago Closed 12 years ago

connecting to running process with specified application-id fails


(Toolkit :: Startup and Profile System, defect)

1.9.0 Branch
Not set





(Reporter: mozilla, Unassigned)




(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080311 Firefox/

set-up: multiple Firefox processes are running using different profiles.

objective: open a url in a specific process from the command-line (either new tab or new window).

problem: depending on the command-line options, the url is either opened in the wrong process or the attempt fails with an error message.

Reproducible: Always

Steps to Reproduce:
1. create 2 profile p1 and p2 
2. firefox -P p1 -a a1
3. firefox -P p2 -a a2

1. firefox  -a a2       -new-tab <url>
2. firefox  -a a2 -P p2 -new-tab <url>
3. firefox        -P p2 -new-tab <url>
4. firefox  -a a2       -remote "openurl(<url>,new-tab)"
5. firefox  -a a2 -P p2 -remote "openurl(<url>,new-tab)"
6. firefox        -P p2 -remote "openurl(<url>,new-tab)"

Actual Results:  
Results of tests 1-6:
1. launches a new process using default profile and opens url therein
2. error message (pop-up): "Pop-up "Firefox is already running, but is not responding."
3. opens tab in process a1
4. error message (stderr): "Error: No running window found"
5. error message (stderr): "Error: No running window found"
6. opens tab in process a1

Expected Results:  
Expected  results for tests 1-6:
1. open url in process a2
2. open url in process a2
3. ???
4. open url in process a2
5. open url in process a2
6. ???
This problem was reported for version in Debian Bugs: The Debian maintainers seem to be under the misapprehension that this was an Iceweasel-specific problem and have merged it with various other Iceweasel bugs.

It was also reported by another Debian user in the Firefox support forum for version

Please, note that, after having encountered the problem with Debian Iceweasel, I downloaded Firefox to carry out above tests.
Looking at the Firefox source code, I realize that the second sentence of the error message for test 2 is significant:

The full message is "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 repeated above tests: I noticed that test 3+6 sometimes produce different results:

Test 3:
result a) opens tab in process a1
result b) error pop-up "Firefox is already running, ..."

Test 6:
result a) opens tab in process a1
result b) error message (stderr): "Error: No running window found"
I submitted a patch for Iceweasel on

I presume that this can also be applied to Firefox.
just adding the patch from Tarlika Elisabeth Schmitz to get it reviewed/commented
Attachment #339048 - Flags: review?
I can confirm the behavior the original submitter is seeing on Firefox 3.0.4 on OpenSuSE 11.x.  Essentially, the firefox -a option is being ignored when opening remote windows - the new tab or window always comes up in the process/profile that was first opened.

This causes usability problems when using multiple profiles at the same time (for instance a "regular" browser and one for development, or like me - one for GMail as an application interface).  You can't control which process gets the new windows, etc for links opened from other applications, clicking the icon on the desktop, etc.  The end result is windows opening up in unexpected places or error messages about Firefox not responding.
I have tested version 3.0.5. The bug still exists.

As the toolkit/xre/nsAppRunner.cpp source code has changed I have created a new patch which fixes the problem.

Please, note that I am running Debian Iceweasel 3.0.5. The patch was created for Iceweasel but the source files should be identical Firefox'.
Version: unspecified → 3.0 Branch
Attachment #359566 - Flags: review?(ted.mielczarek)
Component: General → Startup and Profile System
Product: Firefox → Toolkit
QA Contact: general → startup
Version: 3.0 Branch → 1.9.0 Branch
Comment on attachment 359566 [details] [diff] [review]
patch for version 3.0.5

bsmedberg is the right person to review this.
Attachment #359566 - Flags: review?(ted.mielczarek) → review?(benjamin)
Ever confirmed: true
Comment on attachment 359566 [details] [diff] [review]
patch for version 3.0.5

If nothing else, the default application name needs to remain gAppData->name. In no case should gAppName be null by the time you get to remoteService->Startup
Attachment #359566 - Flags: review?(benjamin) → review-
Attachment #339048 - Attachment is obsolete: true
Attachment #339048 - Flags: review?
Blocks: 393645
My objective was objective to open a url from the command-line in a specific browser profile  (either new tab or new window).

I realized later that this could be achieved using the existing options. Therefore my patch was superfluous.

I use a shell script to fire up a link in the desired profile:

firefox -P $PROFILE -remote "ping()"
if [ ! $? == 0 ]; then
    firefox -P $PROFILE -no-remote $URL
    firefox -P $PROFILE -remote "openurl($URL,new-tab)"

which I can call from my email or RSS client.
I notice from that the -no-remote feature, which my solution is based on, no longer works in new versions of Firefox. But as I am still on 3.5.8, this is not relevant to me.
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.