1521443 - *any* new tab created while in a container tab should be in that container

Status: NEW

(Core :: Security, defect, P3)

Description

[Dietrich Ayala (:dietrich)]

STR:

1. Working in a container tab
2. cmd+t to open a new tab

Expected: new tab opens in same container as active tab when i executed cmd+t

Actual: new tab is in default container (containerless?)

This should have UX review, as "new tab == new task" model is the default in Firefox, and this would seem to be in conflict with that model.

Comment 1

[Danny Colin [:sdk]]

What would you propose as an alternative shortcut to open a tab in the default
container?

Default container is probably the one that people tends to use the most. Losing the
ability to quickly open a tab with a shortcut in default would be a major downside
for a lot of users out there.

Comment 2

[Albert Scheiner [:alberts]]

Default container is probably the one that people tends to use the most. Losing the
ability to quickly open a tab with a shortcut in default would be a major downside
for a lot of users out there.

FWIW, when I am in a container tab most of the time I actually want to stay in this container context when opening yet another tab.

What would you propose as an alternative shortcut to open a tab in the default
container?

Maybe Cmd + opt + t / Shift + Alt + t ?

Comment 3

[Danny Colin [:sdk]]

FWIW, when I am in a container tab most of the time I actually want to stay in this container context when opening yet another tab.

We can't assume that your (or my) workflow is the same as the majority of folks who use containers :).

Maybe Cmd + opt + t / Shift + Alt + t ?

Doesn't seems to be in use at the moment so +1 for that shortcut. IMHO, I think Ctrl + t should stick to the
actual behavior (opening a tab in the default container) and shift + alt + t (or whatever else) should open in
the same container.

Why I'm suggesting that? Because it will not break the actual shortcut behavior. We need to remember that people who
don't use containers are probably also using ctrl + t to open a new tab. Changing that shortcut behavior will break their
expectations.

Comment 4

[(no longer active)]

baku, what do you think about fixing this bug? I think this would be a huge win in terms of the usability of containers in Firefox!

Comment 5

[Andrea Marchesini [:baku]]

When developing containers, we discussed this issue several times, but we've never found a good UX design/configurations. All the shortcuts seems to be already taken. Tanvi, do you remember what was decided at the end?

Comment 6

[Tanvi Vyas[:tanvi]]

For now, we shouldn't change the default behavior of Ctrl+t. Different users expect different behaviors.

• We could add a pref life privacy.userContext.inheritTabType = true/false. It would be set to false by default. Users could change the pref value to make Containers work the way they want them to (for those that want new tabs to inherit). Extensions could also make that decision based on their extension UX.
  ** (For example, for Facebook Container, this value should remain false, because users should only be in the Facebook Container when they are on facebook.com. A new tab in the same container type is only useful if they are going to again navigate to facebook.com in it).

• Alternatively, a keyboard shortcut to open a tab with an inherited container context would be really great! I would use it everyday, as that is one of the biggest pain points for containers power users. But - we have to find an available hotkey. If we can find it, then go for it!

Note that if you have the Multi-Account Containers extension, you can use "Ctrl + ." to open the popup menu. Then tab through the containers to open the one you want. Not great, but works if you really don't want to use your mouse. There are some other tricks you can use, but the rest all require a mouse.

Comment 7

[Danny Colin [:sdk]]

For now, we shouldn't change the default behavior of Ctrl+t

Totally agree, not every users are using containers. We should definitely avoid to change
hotkey that would affect 100% of FF users.

We could add a pref life privacy.userContext.inheritTabType = true/false.

That's a good first step. But ultimately, searching in the about:config isn't really ideal.
With all the options related to containers wouldn't it make more sense to add a section
dedicated to it in about:preferences in the future?

we have to find an available hotkey. If we can find it, then go for it!

Hotkey in Firefox are becoming a scarce resource these days. :)

Comment 8

[(no longer active)]

If the user has the Multi-Account Containers installed, is there any good reason why Ctrl+t shouldn't have the behaviour proposed here by default?

(I agree that is not the right behaviour for extensions like Facebook Container. Once we decide what the right default behaviour for Ctrl+t is, we can of course add a pref to deactivate that and use that in Facebook Container.)

I think finding a different keyboard shortcut for this task will have the disadvantage that only users who have seen this bug will be aware of it. Keyboard shortcuts aren't really discoverable.

Comment 9

[Dietrich Ayala (:dietrich)]

Making cmd/ctrl+T stay in current container is why I filed this bug.

I'm asserting that for container users, staying in container is the expected default behavior.

Being teleported away from the current container is unexpected behavior that breaks the task flow of containers as a feature.

If I'm a container user, and am on a tab that is part of a container, then a new tab created by me using cmd/ctrl+T is expected to be in that container.

For people who are not container users, there is zero change in behavior.

(Aside: From a design perspective, it's difficult to reason about this without having a task-oriented model to work within. The containers feature being partially in core and partially in extensionland makes the whole thing a bit wonky.)

Comment 10

[Ethan Tseng [:ethan]]

Luke, could you find someone to triage this bug?

Comment 11

[Danny Colin [:sdk]]

(In reply to Dietrich Ayala (:dietrich) from comment #9)

Making cmd/ctrl+T stay in current container is why I filed this bug.

It'd still want a way to quickly open a non-containerized tab even if I'm a container user. Maybe a good compromise should be to have a shortcut for both action and expose them in the shortcut manager. Any thought on that?

Comment 12

[Luke Crouch [:groovecoder]]

Marking as P3 - regular priority bug.

Comment 13

[Roy Orbitson]

The main GiHub issue for this is still getting "me toos". There have been several duplicates, and many similar & related bugs both there and here on Bugzilla (e.g. bug 1245262, bug 1318352). It's clearly something users want. There are always more affected users than speak up about it.

I wrote an addon for this, but there are others, none of which can use the default shortcut because of bug 1320332. Because of the latter, they don't alleviate the problem of having to be conscious of staying in the current container. I'm not alone in preferring more steps to break out to the default container.

I'm also of the opinion that the current behaviour is an insecure default, but a pref would be better than nothing. If active, the File > New Container Tab submenu would need the same No Container option that the + new tab button's context menu has. Breaking out of a container would then be as easy as Alt + F, B, Enter.

Comment 14

[Danny Colin [:sdk]]

I wrote an addon for this, but there are others, none of which can use the default shortcut because of bug 1320332.

Since you have knowledge in coding, you could propose a patch. I haven't looked closely but it's probably possible to implement this in Firefox from the JS side of it. You can look at the quick guide (https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html) and ask questions on chat.mozilla.org in either #introduction:mozilla.org or #containers:mozilla.org.

Comment 15

[Roy Orbitson]

Attachment: pref-retain-container-new-tab.patch

I wrongly assumed it would be difficult to set up a dev environment. I am impressed by how easy Mozilla makes it.

I had a go, using browser.tabs.newInCurrentContainer as the pref name. It works for me without errors in the Browser Console. I added an Alt + click override to break out of a container, when the click is on either the + button or the File > New Tab item (if opened with Alt + F and Alt remains held). It doesn't seem to interfere with BrowserUtils.whereToOpenLink. I didn't write a component test for it.

I'm not entirely sure about retaining context for new windows. The patch retains the context on new windows opened by Shift + Click on the + button (unless Alt is also held), but windows opened from the File menu or with Ctrl + N do not retain the context. It should probably be all one way or the other, but if it does retain the context, then the Alt break out would not be reliable because Ctrl + Alt + ... is frequently used for OS-level shortcuts. Maybe it should drop context in that case.

It's such a small patch, so I feel like I'm missing something.

Comment 16

[Danny Colin [:sdk]]

Awesome! I'm really glad to hear it was easier than you thought. I won't be able to review it this coming week since there's a pan-Mozilla workweek but I'll make sure I'll do it before the end of august.

In the meantime, do you mean pushing your patch again but this time on our Phabricator instance. You can find the docs on https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html

The tl;dr is:

1. Your commit needs to have the follow formatting: Bug 1521443 - you message r=sdk (sdk is my username so it will auto-tag me as reviewer)
2. Use moz-phab submit (See the link I shared above)

Again, thank you for your contribution!

Comment 17

[Dietrich Ayala (:dietrich)]

For now, we shouldn't change the default behavior of Ctrl+t

Totally agree, not every users are using containers. We should definitely avoid to change
hotkey that would affect 100% of FF users.

That's the great thing about changing the default cmd/ctrl+t:

It would affect exactly zero users who do not use containers!

(In reply to Danny Colin [:sdk] from comment #11)

(In reply to Dietrich Ayala (:dietrich) from comment #9)
It'd still want a way to quickly open a non-containerized tab even if I'm a container user. Maybe a good compromise should be to have a shortcut for both action and expose them in the shortcut manager. Any thought on that?

While I love that someone put in the time for a patch and I certainly like a keyboard shortcut, it's a different issue than this issue I filed, which is specifically to change the default behavior of cmd/ctrl+t.

Comment 18

[Roy Orbitson]

I very much agree that the default should be changed so that context is preserved. I think that's the least unexpected path. However, the Mozilla devs have consistently decided against this in all the discussions I've come across, so I think we'd need some kind of blessing before submitting a patch that changed it.

You never know, having this patch accepted would allow Mozilla to just change the default for that pref at some future date.