1069263 - launching "firefox -private" if firefox is already launched modifies the behavior of "-new-tab" and "-private-window" command line flags

Status: NEW

(Firefox :: Private Browsing, defect, P3)

Description

[Kevin]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140912222815

Steps to reproduce:

1. open firefox
2. open private window (ctrl+shift+p)
3. open terminal
	behavior of the following commands is as expected:
	* firefox -new-window http://example.com
		always opens the url in a new non-private window
	* firefox -new-tab http://example.com
		always opens the url in a new non-private tab (creates new non-private window if none exists)
	* firefox -private-window http://example.com
		if a private window exists:
			opens in new private window tab
		else (no private window exists):
			opens in new tab in existing private window

	sidenote: -private-window should probably be renamed to -private-tab since it's analogous to -new-tab, and not -new-window

4. type: "firefox -private"
	* undefined behavior since firefox is already open: currently just opens a new (non-private) window



Actual results:

5. now typing the previous commands will now unexpectedly (and incorrectly) behave differently:
	* firefox -new-window http://example.com
		same behavior (unaffected)
	* firefox -new-tab http://example.com
		wrong behavior: now opens the url in whichever window has focus last, private or not.
	* firefox -private-window http://example.com
		wrong behavior: same behavior as previous case (opens in new _tab_ in whichever windows had last focus)



Other side effects (secondary bugs after typing "firefox -private"):

	1. closing a private window with multiple tabs now asks for confirmation (usually it only asks for non-private windows). I didn't try removing the "Warn me when I attempt to close multiple tabs" checkbox.

	2. opening new private windows (ctrl+shift+p) now opens standard, non-private windows.


Maybe the side effects should be their own bug reports - I'm not sure if (or which) one is causing the others, if there is a common cause behind everything, or if some are unrelated bugs.


Note: I didn't try experimenting with opening "firefox -private" without having firefox already open and seeing if there are any clues there - I don't want to risk losing my session and don't have access to a secondary install or vm right now.



Expected results:

* All three command line flags (-new-window, -new-tab, -private-window) should have maintained their behavior before step4.

* The two secondary bugs should not have happened.

reference: https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Browser

Comment 1

[u484151]

Looks like this is still a thing in Firefox 57.

I noticed I have a typo in the original post: looks like I mistakenly switched the contents of the if/else in the last part of step3.

Comment 2

[tobias]

there is a second bug report about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1381866

(also, can confirm bug with firefox 58beta)

Comment 3

[Paul Merlin]

This issue is still valid!

Using Firefox 121.0.1 on Linux.

If I have a running instance of Firefox with a non-private window open and I run firefox --private-window https://example.com the URL is simply opened in a new tab of the existing non-private window. Nothing is printed to the command line output about Firefox doing something different than what the command asked for. This is pretty confusing and if not paying attention the user can assume he's browsing in private mode but they're not.

If I already have a private-window open and that window was the last focused one then firefox --private-window https://example.com opens the URL in the private window.

It looks like the --private-window command line argument only has an effect if used alone to start a blank new private window and is simply ignored in other cases.

If I run firefox --private-window ; firefox https://example.com then the first part of the command will open a new private window and the second part of the command will open a new tab in the private window with the URL. But this feels very wrong and ends up with an unnecessary empty tab opened.

This feels like the command line is simply broken.

There have been several related bugs around this opened/closed and regressions observed over the years (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1442749 , https://bugzilla.mozilla.org/show_bug.cgi?id=1598290 ...). I also found https://bugzilla.mozilla.org/show_bug.cgi?id=1445674 which acknowledges the fact that this area isn't properly tested. I assume there is some complexity related to this that I don't grasp but I feel this is something that should be addressed somehow. Any chance this could be prioritized?

Comment 4

[Tim Huang[:timhuang]]

I think this is related to the Firefox launcher. Ray, could you provide your insight here? Thanks.

Comment 5

[Ray Kraesig [:rkraesig]]

Exceedingly unlikely. The launcher process' involvement is over and done with before we pass any data to an already-open instance of Firefox, and it doesn't process the -private flag. [1] Also, we didn't have a launcher process in Firefox 32.

[1] (The only place in the entire application that I can find where the -private flag is processed is here, in BrowserContentHandler.sys.mjs. The comments there reference a "global PB Service" that also uses it, but I don't know of such a thing.)

Comment 6

[Paul Merlin]

Note that I was not using -private at all in my tests, only --private-window

Comment 7

[Paul Merlin]

Looking at the code in https://searchfox.org/mozilla-central/source/browser/components/BrowserContentHandler.sys.mjs#88-117 I played around with launcher arguments and figured something that looks to work, at least on Linux: firefox --private-window firefox-private:https://example.com does what I wanted: open the provided URL in a private window. But I could not find any documentation anywhere about this. If this even expected? Won't this break in the future if this area is taken care of?

Comment 8

[Paul Merlin]

FWIW this also seems to work: firefox --private-window firefox:https://example.com

Comment 9

[Masatoshi Kimura [:emk]]

Apparently firefox: and firefox-private: protocols are added for dual browser extension (bug 1862450). Don't ask me what is dual browser extension. That's what I want to ask. Mozilla becomes more and more secretive.

Comment 10

[Ray Kraesig [:rkraesig]]

(In reply to Paul Merlin from comment #6)

Note that I was not using -private at all in my tests, only --private-window

Ah! The bug title specifies "firefox -private", so I'd assumed you had run that prior to the tests in that comment. I'd say you're describing a different bug than this one. Note in particular that the original reporter says that firefox -private-window http://example.com works correctly before invoking firefox -private!

In particular, I suspect you've hit a much more recently-introduced bug. Can you use mozregression to check if so, and possibly isolate the regression point? (mozregression creates and runs a series of temporary Firefox installations; but the location of those installations should be printed out in the bottom pane of the mozregression GUI window, so you should be able to invoke them directly from a terminal window.)

For what little it's worth: I have just tested on Windows, both with my current install of Firefox and via mozregression, and can't repro here.

---

(In reply to Paul Merlin from comment #7)

But I could not find any documentation anywhere about this.

I'm with :emk about this — I have no idea what's going on here, and I wouldn't rely on it long-term. (But it should be fine for a temporary workaround.)

Comment 11

[Paul Merlin]

Yep I confirmed that I don't observe the bug on Windows earlier Today.
It is definitely present on Linux (Ubuntu default Firefox install, snap I believe).

mozregression looks nifty but this raises a few questions.
What version should I use as a boundary for the bisect?
The bug happens when running from the command line while there's already an instance running, I don't see any option in mozregression to help me find the culprit, any tips?

Comment 12

[Ray Kraesig [:rkraesig]]

(In reply to Paul Merlin from comment #11)

Yep I confirmed that I don't observe the bug on Windows earlier Today.
It is definitely present on Linux (Ubuntu default Firefox install, snap I believe).

... I can all too easily see this being a snap-related bug.

mozregression looks nifty but this raises a few questions.
What version should I use as a boundary for the bisect?

We don't actually know if this is a regression at all, so the default of "one year ago" is probably fine; but you can set it to four years ago for the cost of only two additional bisections.

The bug happens when running from the command line while there's already an instance running, I don't see any option in mozregression to help me find the culprit, any tips?

On each bisection, mozregression will start a new instance of firefox, so that'll be the "while there's already an instance running" criterion satisfied. You can then copy the path to that instance's executable from the bottom pane of the GUI window, paste it into a separate console window, and append the necessary arguments to perform the actual test.

Comment 13

[Andrew]

(In reply to Paul Merlin from comment #8)

FWIW this also seems to work: firefox --private-window firefox:https://example.com

Unfortunately, it or firefox-private: doesn't seem to work anymore (v136.0.3). From what I'm reading, it looks like it was the only workaround.