1977140 - --private-window command line option malfunctions

Status: NEW

(Firefox :: Private Browsing, defect, P3)

Description

[Ryan Colyer]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

1. Open firefox to any web page in non-private mode. Then on the command line run:

firefox --private-window https://google.com

2. Open firefox to any web page in private mode. Then on the command line run:

firefox --private-window https://google.com

Actual results:

1. A non-private tab (not a window) opens to google.com.
2. A private tab (not a window) opens to google.com.

Expected results:

1. A new private window opens to google.com.
2. A new private window opens to google.com.
   Note that firefox --help reports "--private-window <url> Open <url> in a new private window." So this expected result is simply for it to do what the --help says it will do, which is an extremely useful basic feature for opening new private windows. Opening tabs is unhelpful as a replacement because those tabs can be buried deeply in the interface behind other windows and might not even be on the same virtual desktop (so raising doesn't help), whereas a new private window will rise to the top of the display in the current virtual desktop, which would be the reason to choose this command line option. I believe this useful command line functionality might have ended up as a victim of a settings change done to fix #829180 regarding an ambiguity. But this is a separate problem, because the command line option which is very explicit about what it should do, opening a new private window to a url, should still be able to do that without any ambiguity.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello, thank you for the bug report!

I could not reproduce scenario 1: With a non-private window opened, upon executing the command a new private window is opened every time, as per the expected results provided in Comment 0.

Ryan, could you please try running the first scenario again using a new profile/troubleshoot mode?

I could reproduce scenario 2: With a private window opened, upon executing the command a new private tab is opened every time.
Tested and reproduced on:

• Windows 10 on Firefox 141.0;
• Ubuntu 22 on Firefox 140.0.1, Firefox 141.0b9 and Firefox 142.0a1(snap builds).

Since I was able to reproduce scenario 2 I will set this bug as NEW so the developing team can have a look.

Comment 3

[Ryan Colyer]

Confirmed, when I switch to a new profile scenario 1 does not happen, but scenario 2 still does. From a diff of profile prefs.js I've determined that the critical parameter which caused scenario 1 was: user_pref("browser.link.open_newwindow", 2); and removing that preference setting causes scenario 1 to not happen. From the mozillazine knowledgebase: https://kb.mozillazine.org/Browser.link.open_newwindow this parameter setting is supposed to do: "Open links, that would normally open in a new window, in a new window (Default in Firefox 1.5 and older)." It seems this setting is also not doing what it says on the label in combination with --private-window, as nothing indicates it should divert to a non-private window when this is set. But perhaps that could be considered a separate issue, or just be considered a documentation shortcoming. For my purposes removing the setting has resolved the behavior of scenario 1. That leaves only scenario 2, where --private-window is opening a private tab instead of a window.

Comment 4

[Brian]

Happens somewhere in the Firefox 130 releases as well, it's not a super recent issue.

Comment 5

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:timhuang, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Tim Huang[:timhuang]]

It looks like we will reuse the existing private window to open the URL if private-window is given.

Dave, do you think we need to change the behavior to open a new window instead of reusing the existing one in this case?

Comment 7

[Dave Townsend [:mossop]]

As far as I can tell ever since it was implemented in bug 960600 this has been the behaviour, we open a new tab if a window already exists. It looks to me like the error was when the help text was added in bug 1030779. I think we should change the help text to match the current behaviour rather than changing the behaviour that has been in place for more than 10 years.

Comment 8

[Ryan Colyer]

Well, the command line option in question is --private-window rather than --private-tab, and tabs are not windows. Bugs slipping in and going unnoticed for a bit is just normal development, but I think it would be pretty wild to intentionally make a named window opening option open tabs instead. There's a very strong functional reason why this is not a good substitution as well, since it causes newly opened "windows" to just randomly invisibly disappear when virtual desktops are in use and a browser window happened to be left open on another desktop. It is to the user as if the command to open a new window was never executed, when really it just sniffed out a hidden window on another desktop and invisibly shoved the new window into a tab on that. The remaining command line options leave no remedy I can find to make the attempt at opening a new window actually reliably open one and have it come up and be displayed. If "really actually open this url in a new private window" is achievable in some other way, I'd love to hear what it is.

Comment 9

[Dave Townsend [:mossop]]

(In reply to Ryan Colyer from comment #8)

Well, the command line option in question is --private-window rather than --private-tab, and tabs are not windows. Bugs slipping in and going unnoticed for a bit is just normal development, but I think it would be pretty wild to intentionally make a named window opening option open tabs instead.

This has been the behaviour since the feature was first implemented so is this a bug or is this the intentional behaviour? From bug 960600 comment 0 the original request was "to open URLs in a private window (using an existing private window if one exists)" and there isn't any discussion suggesting anything else so I don't think this is a bug. If the argument were named --new-private-window I would likely agree with you but I don't think it's unreasonable to interpret --private-window as "open this in a private window, existing or new". In hindsight the original patch which used the name --new-private-tab makes more sense to me but unfortunately since this has been the behaviour for over 10 years, changing it now will likely break someone relying on the existing behaviour.

I guess we could consider adding a --new-private-window but given that as far as I can tell no-one has filed a similar issue I'm not entirely convinced that there is a strong need. I'd much rather see us fix the underlying issue that you seem to be working around.

There's a very strong functional reason why this is not a good substitution as well, since it causes newly opened "windows" to just randomly invisibly disappear when virtual desktops are in use and a browser window happened to be left open on another desktop. It is to the user as if the command to open a new window was never executed, when really it just sniffed out a hidden window on another desktop and invisibly shoved the new window into a tab on that.

We should be attempting to focus the other window in this case or doing something that might help a virtual window manager to highlight that this has happened. If not we should probably file a bug for that. Presumably the same problem happens if you happen to only have a private window on the current desktop and a normal url is sent to a normal window on another desktop.

Comment 10

[Ryan Colyer]

(In reply to Dave Townsend [:mossop] from comment #9)

This has been the behaviour since the feature was first implemented so is this a bug or is this the intentional behaviour? From bug 960600 comment 0 the original request was "to open URLs in a private window (using an existing private window if one exists)" and there isn't any discussion suggesting anything else so I don't think this is a bug. If the argument were named --new-private-window I would likely agree with you but I don't think it's unreasonable to interpret --private-window as "open this in a private window, existing or new". In hindsight the original patch which used the name --new-private-tab makes more sense to me but unfortunately since this has been the behaviour for over 10 years, changing it now will likely break someone relying on the existing behaviour.

Well the behavior of --private-window without a url was carried over in bug 960600, which is to always open a NEW window. The option continues to do that to this day, regardless of what else is open. It is only when a url is provided that the new window disappears into the ether if other things are open elsewhere, providing two completely different user experiences in a single option. This is a pretty intrinsically weird contradiction. If the option of changing the help is chosen, then those are probably going to have to be separated apart as if they're two options with the same name, just to be able to explain it clearly.

I'd much rather see us fix the underlying issue that you seem to be working around.

Well, sure. The underlying issue is simply a full inability (as best I can tell) to open a new private window to a url by any mechanism. Finding the documented behavior in the Firefox help broken a long time ago, I assumed (without checking) that it was a simple known bug (since the help seemed so clear as to the intended behavior), and I've been using chromium since then to do this (with --new-window --incognito). But when to my surprise I recently noticed the stated behavior still doesn't work in Firefox, I realized it must have gone unnoticed. But any approach to opening a private window to a url would do the job, as long as the help correctly labeled this functionality.

We should be attempting to focus the other window in this case or doing something that might help a virtual window manager to highlight that this has happened. If not we should probably file a bug for that.

Well, definitely don't go down that path. Virtual desktops are a workspace segmentation. Applications shouldn't be tossing things across them of their own volition, nor should they forcefully override the segmentation that the users have setup by manually switching between desktops. Applications should keep activity on the virtual desktop where they are actually being used. Workspace segmentation exists for a strong user-focused purpose.

Presumably the same problem happens if you happen to only have a private window on the current desktop and a normal url is sent to a normal window on another desktop.

This works reliably fine. This is the --new-window option, and it performs as labeled, always opening a normal new window to the specified url. Only --private-window is hunting down recently used windows and opening tabs, so the only missing behavior is the ability to open urls to new private windows.

Ironically there IS a buggy secondary behavior if one does "firefox --new-window --private-window <url>" at which point the url opens to a non-private tab on an existing window, somehow merging the most confused elements of these features to make the private window non-private and not a window. Presumably this goes down an unplanned and untested path in the option conditionals.

Comment 11

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:timhuang, could you have a look please?

For more information, please visit BugBot documentation.