845592 - New Private Window entry in File menu doesn't make sense in permanent private browsing

Status: RESOLVED FIXED

(Firefox :: Private Browsing, enhancement)

Description

[Eiichi]

Attachment: Screenshot.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130220104816

Steps to reproduce:

1. Open "File Menu" when using normal browsing mode.
2. Open "File Menu" when using private browsing mode.



Actual results:

We see exactly the same "File Menu".


Expected results:

We expect different "File Menu" like as Opera Browser.
As Firefox tries to have dual mode windows and tabs, it needs dual mode "File Menu": for normal browsing mode and for private browsing mode.
So we can select "Normal Browsing" or "Private Browsing" from the "File Menu" in each of windows or tabs.

Screenshot is coming...

Comment 1

[Josh Matthews [:jdm]]

Eiichi, what differences are you actually looking for? All of the menu entries in the File menu make sense for both public and private browsing, so there's no point in hiding them.

Comment 2

[Eiichi]

(In reply to Josh Matthews [:jdm] from comment #1)
> Eiichi, what differences are you actually looking for?

1. Opera's Menu enables users to open a new tab in "Normal Mode" or "Private Mode" in the current window.
2. Opera's Menu enables users to open a new window in "Normal Mode" or "Private Mode" instead of the current window.

3. But Firefox's Menu can't do them.

Comment 3

[Josh Matthews [:jdm]]

Thanks for the suggestion, but I don't see any reason to limit the actions available to the user unnecessarily.

Comment 4

[Eiichi]

(In reply to Josh Matthews [:jdm] from comment #3)
> Thanks for the suggestion, but I don't see any reason to limit the actions
> available to the user unnecessarily.

Only for the record;
When I set to "Always use private browsing mode" in the preferences, "New window" acts like "New Private Window".
That confused me.
Why does "New Window" open in the private mode not in the normal mode?

Comment 5

[Josh Matthews [:jdm]]

That's actually a good point. Let's focus on correcting that problem.

Comment 6

[Eiichi]

I think "New Private Window" is advisable to be dimmed when users set to "Always use private browsing mode" in the preferences.

Comment 7

[Eiichi]

When users set to "Always use private browsing mode" in the preferences, they have an assumption that "New Tab" means "New Private Tab" and "New Window" means "New Private Window".

Comment 8

[Josh Matthews [:jdm]]

I wouldn't block the release of the feature on this, though.

Comment 9

[eyal gruss]

same issue may also be relevant when right clicking on a link

Comment 10

[Eiichi]

Attachment: Screenshot when right clicking on a link

(In reply to eyal gruss (eyaler) from comment #9)
> same issue may also be relevant when right clicking on a link

Screenshot when right clicking on a link

Comment 11

[(no longer active)]

Attachment: Patch (v1)

Comment 12

[Josh Matthews [:jdm]]

Comment on attachment 721042 [details] [diff] [review]
Patch (v1)

Review of attachment 721042 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not a good reviewer here.

Comment 13

[Eiichi]

For reference:

Now,
1. New Window (Command + N) opens the page that users set in "Preferences > General > When Firefox starts".
2. New Private Window (Shift + Command + P) opens the "about:private browsing".

When users set to "Always use private browsing mode" in the preferences, they know what permanent private browsing means.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 721042 [details] [diff] [review]
Patch (v1)

>diff --git a/browser/base/content/test/browser_private_browsing_window.js b/browser/base/content/test/browser_private_browsing_window.js

>+        isnot(newWindow.label, newPrivateWindow.label, "New Window's label should be overwritten");
>+        isnot(newWindow.accessKey, newPrivateWindow.accessKey, "New Window's accessKey should be overwritten");
>+        isnot(newWindow.command, newPrivateWindow.command, "New Window's command should be overwritten");

These test descriptions need to be adjusted (s/should/shouldn't/).

Comment 15

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dab2619094d4

Comment 16

[(no longer active)]

Comment on attachment 721042 [details] [diff] [review]
Patch (v1)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): PBnGen
User impact if declined: See the bug description.  This can cause confusion for users of permanent PB mode.
Testing completed (on m-c, etc.): Locally, patch includes a test case.
Risk to taking this patch (and alternatives if risky): Not very risky.
String or UUID changes made by this patch: None.

Comment 17

[(no longer active)]

Backed out because of a linux browser-chrome bustage: https://hg.mozilla.org/integration/mozilla-inbound/rev/8a1ef77e58f6

Comment 18

[bhavana bajaj [:bajaj]]

Holding off on approval unless it can land without issue on trunk - will revisit and watch for an update .

Comment 19

[Josh Matthews [:jdm]]

Attachment: Adjust the New Window menu entries in permanent private browsing mode;

Comment 20

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/116a46d187fe

Comment 21

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/116a46d187fe

Comment 22

[(no longer active)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f4bc84749a75

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 721042 [details] [diff] [review]
Patch (v1)

Looks like this landed ok now - approving for beta uplift so we can get this in tomorrow's fifth week beta build.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a44fb6380889

Comment 25

[Ioana (away)]

Verified as fixed on Firefox 20 beta 6 (20130320062118), Mac OSX 10.7.5 and Windows 7:
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20100101 Firefox/20.0

Comment 26

[Eiichi]

On Firefox 20 beta 6 (20130320062118), Mac OSX 10.7.5;
1. Click "New Private Window" of File Menu opens the "about:private browsing".
2. "Command + N" shortcut opens the page that users set in "Preferences > General > When Firefox starts".

Comment 27

[Ioana (away)]

This is another bug Eiichi. It existed before this bug got fixed.

Please file it separately.

Comment 28

[Eiichi]

(In reply to Ioana Budnar [QA] from comment #27)
> This is another bug Eiichi. It existed before this bug got fixed.
> 
> Please file it separately.

Sorry, I filed Bug 853996.

Comment 29

[Ioana (away)]

Verified as fixed on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0

Comment 30

[Tiziana Sellitto [:tiziana]]

The bug is Verified fixed on Firefox Aurora 22.0a2 – 20130407004016: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20130407 Firefox/22.0

but if I use the single right click on the Firefox (20/21/22) dock icon on Mac OS X there is the "New Window" and the "New Private Window" menu even if in permanent private browsing and the "New Window" opens a private window since we are in the permanent private browsing.

The point whom  I was thinking about is: "If the "New Window" entry in File menu doesn't make sense in permanent private browsing, why it does in the dock menu?"

Comment 31

[Josh Matthews [:jdm]]

It doesn't. Feel free to open a new bug for that!

Comment 32

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old