I traced the enabling/disabling code back as far as https://chromium.googlesource.com/chromium/src/+/ef3a0f2426d7d5618a7b0503b4b0260c8d616dc9 - Evan, do you know if this is WAI?

Able to reproduce this issue on Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest stable #59.0.3071.115. This issue is seen on older version of chrome M35-35.0.1849.0, Hence marking it as untriaged.

Patch is at https://chromium-review.googlesource.com/c/564579/

This patch changes the enabled/disabled states:
- In Normal mode, all are enabled
- In incognito mode, 
 - "open in new window" is now disabled
 - "open in incognito window" is now enabled

It seems like it's WAI to me, because the code looks pretty intentional (also I'd be surprised if this isn't covered by unit tests). Perhaps  design should weigh in on what the correct behavior should be. I am ok with the new described behavior.

I think the current behavior is wrong, but it might be intentionally wrong.

rpop: wdyt? (patch is ready to go)

Hmm, I defer to the owners of incognito, but I prefer the new described behavior as well. +msramek, maxwalker

msramek, maxwalker: Any objections or suggestions?

I'm pretty sure the current implementation is intentional, and I can imagine the thought process behind it (i.e. you're already in Incognito, so a new Incognito window is, well, just a window now).

But I agree that the proposed new behavior would be semantically clearer. It's just going to be slightly confusing for a moment, because the ordering of items is muscle memory (at least in my case) :)

Max, WDYT?

That's interesting: when you say muscle memory, what ui are you using (right click or perhaps the top menu)?

Also, I agree that change aversion is real, and this may confuse users slightly. 

My concern right now is when I'm sitting in an incognito window and see "open in new window", I'm not sure what that means. 

I have "Right click + move a few px right and down" to open a new tab in my muscle memory. I actually don't open new windows that much, so probably no effect on me personally.

Nevertheless, it's also not difficult to retrain this memory. I'm not arguing against the change, just wanted to bring this up.

I agree that the current behavior is a little unclear.

Given the issues with the approaches above, another option would be to make things extra clear and consistent across both modes: "New Tab/Window" in regular mode and "New Incognito Tab/Window" in Incognito mode. See quick mock.

This would mean that we remove the possibility to directly open a link in an incognito window from the context menu. But users could still copy links to an Incognito window. The removal would be a simplification for the context menu in general.

+ Edward who is thinking about menu simplification
Do we have metrics on how often "Open Link in New Incognito Window" is used?

Deleted: Open in Incognito.png 26.3 KB

	Open in Incognito.png 26.3 KB View Download

Hmm. This seems like a rollback of incognito functionality to me if we make people essentially restart a session to use it (or copy paste URL). But let's check usage data if we have it.

Metrics 28 day usage in the context of these three items
- Open link in New tab - 98.4%
- Open link in New Window - 1.3%
- Open link in New Incognito Window - 0.25% 

I'm not sure we can split these by Incognito / regular session.

It's probably a rare occurrence that someone in an incognito session wants to open a link in a regular session. However wouldn't the confusion be solved by allowing users to open links in a regular window from an Incognito state? Then whatever session you are in, both links work as expected without the user thinking about the context they are in. 

I understand there could be potential consequences as users learn the change, but as the incognito link is now enabled this should be an indicator to choose this one (except in the cases of muscle memory of always choosing the second menu item). Also the incognito window is pretty distinct so you would know if you made a mistake.

Regarding #10: Thanks for describing the muscle memory angle - that's a good point, and I think my original suggestion wouldn't change the flow for "right-click, open in new tab".

Regarding the mocks in #11, I'm not clear what the win is for removing "open in incognito window" from the regular mode dialog. I would argue that "consistency between the two menus" probably isn't significant, especially if we're concerned about change aversion. (Agree with rpop's comments in #12)

Regarding #12/#13: Note that we stop collecting uma stats once an incognito window opens. So, no, we won't be able to make meaningful inferences here.

Regarding an incognito user wanting to go "regular", that option is available on the app menu. I would argue that this will meet our user's needs.

Wow, that's a lot of regardings;) Perhaps I should draw this discussion back to the original complaint: when I right-click in an incognito window, there are three options presented:
 - open in new tab (which opens the link in a new incognito tab within the current incognito window)
 - open in new window (this option is enabled, and it opens in a new incognito window)
 - open in incognito window (this option is not enabled)

It seems surprising that the second option does something different in incognito vs regular mode. Really this menu item could be called "open in a new window of the default type", or "open in a window just like this one".

It also seems surprising that "open in incognito window" is disabled. So I'm fairly confident that "open in incognito window" should be enabled when you're in incognito mode. If anyone disagrees on this point, please speak up.

That leaves the question: what should we do with  "open in new window" when you're in incognito mode. Options:
1) leave it in place and enabled, and change the operation to open in a non-incognito window.
2) leave it in place and enabled, and keep the operation as it is (opening the link in an incognito window) [makes this a redundant operation - this is a bad option]
3) leave it in place and disabled
4) remove it from the menu

At this point, I'm leaning to #4, but would also consider #3 to be an option. I would argue that #2 is silly, and that #1 would be confusing to our users - it used to do something different, and also the proposed operation was not previously available from the context menu.

Would anyone object to #4 as a solution?

Option 1 is not only confusing, but actively bad – it's entirely possible that someone who is doing something private in incognito mode could press "Open in new window", expecting it to open in an incognito window (current behaviour), but it instead opens in a normal window, which is potentially a big problem for them, and at minimum a pain (have to clear history, cache, ...). In general, I feel that getting data out of incognito mode and into normal mode should be harder than getting data from normal mode to incognito mode, because (for example) accidentally opening a link in incognito is much less of a problem than accidentally opening a link in non-incognito.

wrt option 3 vs option 4: I find the disabled menu item a useful indicator that I'm in incognito, and I don't know if a missing menu item would have the same effect.

I created an overview of the options we discussed and added some new options, see attachment.

Option 3 is shown in (C). I think a downside of this option is that it's now slightly unclear whether “New Tab” will open the link in incognito mode or not (since it doesn't mention incognito like the "New Incognito Window" action). Also the gap between the two related items looks a little odd.

What do you think about B? It's very clear what each menu item does. And the first two items are consistent in regular and incognito mode (1st: new tab in current mode, 2nd: new window in current mode).

Deleted: Incognito Context Menu.png 868 KB

	Incognito Context Menu.png 868 KB View Download

Option B looks good to me. It places the "same" items in the same order, and clarifies both what they are doing and the mode that you're in.