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:126.96.36.199) Gecko/20080311 Firefox/188.8.131.52 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. ???
This problem was reported for version 184.108.40.206 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 220.127.116.11: 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 18.104.22.168 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 22.214.171.124 on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472793#22 I presume that this can also be applied to Firefox.
just adding the patch from Tarlika Elisabeth Schmitz to get it reviewed/commented
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)
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-
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.