connecting to running process with specified application-id fails

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
11 years ago
7 years ago

People

(Reporter: mozilla, Unassigned)

Tracking

1.9.0 Branch
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

11 years ago
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. ???
Reporter

Comment 1

11 years ago
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.
Reporter

Comment 2

11 years ago
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."
Reporter

Comment 3

11 years ago
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"
Reporter

Comment 4

11 years ago
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

11 years ago
just adding the patch from Tarlika Elisabeth Schmitz to get it reviewed/commented
Attachment #339048 - Flags: review?

Comment 6

11 years ago
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.
Reporter

Comment 7

11 years ago
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
Reporter

Updated

11 years ago
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)

Updated

11 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

10 years ago
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?

Updated

9 years ago
Blocks: 393645
Reporter

Comment 11

7 years ago
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.