Firefox 9 Fails To Correctly Use -new-window

RESOLVED INVALID

Status

()

Firefox
General
RESOLVED INVALID
6 years ago
5 years ago

People

(Reporter: drichard, Unassigned)

Tracking

9 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
I tested with Firefox 8.0.1 and it works fine with the previous version.  But in Firefox 9, when you issue a -new-window it should use the existing running session and open a new window as a child process.  What Firefox is doing instead is indicating:

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.

It thinks that you are trying to launch FF again.

This seems like a regression.  -new-window is still indicated on the command line as a valid command line flag.

To Replicate:
1) Launch FF and go to any page.
2) From the command line issue firefox -new-window <another site>
3) A new window should open running as a child of the parent session.

We use this feature very heavily with email to allow users to open a link and force the link to open in the current workspace.
(Reporter)

Comment 1

5 years ago
This is broken in the released version (9.0.1) and is a showstopper for us.  We cannot upgrade our users until this is fixed.  The command line help system still shows -new-window as a valid argument, but it doesn't work.

Comment 2

5 years ago
agreed, this is a showstopper for me too.

out of curiosity, are you initially launching firefox with -no-remote? i see the same problem when i launch with -no-remote, but when i launch without -no-remote, -new-window and -new-tab work fine.

more details: http://superuser.com/questions/372573/cant-aim-command-line-at-one-of-multiple-running-instances-since-upgrading-to-f

Comment 3

5 years ago
this might be the root cause: https://bugzilla.mozilla.org/show_bug.cgi?id=650078
(Reporter)

Comment 4

5 years ago
I looked at the scripts and indeed it was previously being launched with -no-remote.  I removed that command argument and now it works.  I think you are right, that the behavior previously was errant and now it's "fixed".   I feel comfortable closing this bug report.

@Ryan:  Reopen if you feel it's still an issue for you.  For me now it's working.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.