427206 - connecting to running process with specified application-id fails

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect)

Description

[Tarlika Elisabeth Schmitz]

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:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

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:
set-up:
1. create 2 profile p1 and p2 
2. firefox -P p1 -a a1
3. firefox -P p2 -a a2

tests:
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. ???

Comment 1

[Tarlika Elisabeth Schmitz]

This problem was reported for version 2.0.0.1 in Debian Bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411505. 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 2.0.0.12: http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=24396&forumId=1


Please, note that, after having encountered the problem with Debian Iceweasel, I downloaded Firefox 2.0.0.13 to carry out above tests.

Comment 2

[Tarlika Elisabeth Schmitz]

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."

Comment 3

[Tarlika Elisabeth Schmitz]

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"

Comment 4

[Tarlika Elisabeth Schmitz]

I submitted a patch for Iceweasel 2.0.0.13 on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472793#22

I presume that this can also be applied to Firefox.

Comment 5

[Noèl Köthe]

Attachment: Patch frim Tarlika Elisabeth Schmitz

just adding the patch from Tarlika Elisabeth Schmitz to get it reviewed/commented

Comment 6

[Brian McDonald]

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.

Comment 7

[Tarlika Elisabeth Schmitz]

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'.

Comment 8

[Tarlika Elisabeth Schmitz]

Attachment: patch for version 3.0.5

Comment 9

[(not currently active) Ted Mielczarek]

Comment on attachment 359566 [details] [diff] [review]
patch for version 3.0.5

bsmedberg is the right person to review this.

Comment 10

[Benjamin Smedberg]

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

Comment 11

[Tarlika Elisabeth Schmitz]

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
else
    firefox -P $PROFILE -remote "openurl($URL,new-tab)"
fi

which I can call from my email or RSS client.
I notice from https://bugzilla.mozilla.org/show_bug.cgi?id=716110 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.