Enhancement: avoiding "Open this site in your assigned container" and "Remember my decision for this site" confirmation dialog misleading by changing confirmation page UI

[achernyakevich-sc]

trafficstars

There is a plenty if GitHub issue like "Remember my decision for this site" checkbox on Open this site in your assigned container? page does not work and so one. It mainly happen because for regular user it is not clear that depending on which button he will click checkbox state could be just ignored. Right now it looks like:

I would propose to change this interface so that it will be more transparent and straightforward. The checkbox and two buttons should be replaced by a selectbox and one Open according to your choice above button. The selectbox would contain the following options:

• Open this site in <ContainerName> container
• Open this site in <ContainerName> container and do not ask again
• Open in Current container
• Open in Current container and forget about assigned container

It could looks like:

And with open options of selectbox:

Having UI organized this way we clearly and straightforward expose to user what would happen and from other side developers could clearly implement behavior for every selected option.

P.S. If an options Open in Current container and forget about assigned container is hard to implement then it could be removed from the list.

[achernyakevich-sc]

It could resolve #2293.

[achernyakevich-sc]

It could resolve #2126, #2105, #1996, #1721.

Potentially it could resolve #2084, #1730.

[achernyakevich-sc]

Another one issue that could be potentially resolved: #1741

[achernyakevich-sc]

Another one issue that could be potentially resolved: #2263, #2320

[achernyakevich-sc]

@maxxcrawford or @groovecoder Maybe you could pay attentions to this issue, mark it by enhancement label and put to development plans? :)

[shtrom]

I would also suggest an extension to the UX to support multiple default containers for some sites, e.g., Personal and Work for GitHub).

In this case, opening GitHub (except when coming from one of those two containers) should always present the selection page, with the choice of both containers, amongst others.

[castlefox]

I got bitten by this bad UI layout and was so annoyed that I created an issue on here. @achernyakevich-sc Was kind enough to show me what was really going on. I must have forgotten that I clicked on that "Remember my decision for this site" and this UI change would totally fix my issue. I have upvoted this idea. I really hope the developers listen this feedback and make this suggested change soon.

[TriplEight]

(not sure if this bug is mentioned anywhere, but when I follow some "Login via google account" type of button that opens a browser-by-default and gets me to this choice-page, regardless of my choice the auth cookie is lost in the process, have to switch the default browser for now :( )

For the better UI/UX I'd suggest adding all the icons of the existing containers, prioritizing the current one by making it a leftmost one and having a checkbox to "remember this for this domain".

[achernyakevich-sc]

For the better UI/UX I'd suggest adding all the icons of the existing containers, prioritizing the current one by making it a leftmost one and having a checkbox to "remember this for this domain".

I'm not sure it would be a good idea. List of configured container could be very long (in some issues I have seen refereces that people had 40+ containers configured), icons could repeat (as MAC has limited set), etc.

What you have seen on screenshot is just trivial work with DOM elements on the page that currently is used. So it is 100% implementable. :)

(not sure if this bug is mentioned anywhere, but when I follow some "Login via google account" type of button that opens a browser-by-default and gets me to this choice-page, regardless of my choice the auth cookie is lost in the process, have to switch the default browser for now :( )

@TriplEight At first glance it looks like not related to this particular GitHub issue. From my side I would add that this is a bad idea to add accounts.google.com site to any container's site list. When you try to authorize via Google it make redirection through this one. So removing it form the site list will make your life easier.

[TriplEight]

I'm not sure it would be a good idea. List of configured container could be very long (in some issues I have seen refereces that people had 40+ containers configured), icons could repeat (as MAC has limited set), etc.

maybe then 3 last ones and "Others.." or something like it. What I was trying to say is that it's not enough to choose from the "current" and a seemingly random "another one".

bad idea to add accounts.google.com site to any container's site list

tbh I'm not sure it's relevant here either, might make sense to create a separate bug for it. But anyway, thanks for an advice, removed it from the list. But now, since it opens outside of any container, it means that I leave the auth cookies of several accounts out of containers. This kills the entire purpose of containerization, no?

[achernyakevich-sc]

I'm not sure it would be a good idea. List of configured container could be very long (in some issues I have seen refereces that people had 40+ containers configured), icons could repeat (as MAC has limited set), etc.

maybe then 3 last ones and "Others.." or something like it. What I was trying to say is that it's not enough to choose from the "current" and a seemingly random "another one".

@TriplEight It looks you wrongly interpret confirmation page purposes and new UI proposed in this issue. I will try to highlight:

• Confirmation page appears only after you defined that some site (only server part of URL could be checked for matching) was marked as Always Open in the container. So you could detect by appearance of the confirmation page that you did it accidentally.
• Confirmation page appears every time when user try to open this kind site until user will confirm that this site should be open exactly in the selected container
• In the proposed UI there is always only two container that this confirmation page could use - one that configured to Always Open in the container and wait explicit confirmation, second one - container that user at the moment before showing confirmation page tried to open a site.

I hope now you understand that proposed UI changes not about managing container assignment per site but exactly about Confirmation page. And it really will stop misleading of people who do not understand why checkbox state is not taken into account when they expect to undo accidentally assigned site per container.

[achernyakevich-sc]

bad idea to add accounts.google.com site to any container's site list

tbh I'm not sure it's relevant here either, might make sense to create a separate bug for it. But anyway, thanks for an advice, removed it from the list. But now, since it opens outside of any container, it means that I leave the auth cookies of several accounts out of containers. This kills the entire purpose of containerization, no?

@TriplEight No, it does not. As technically impossible to check the whole URL matching but only server/port related part so setting Always Open in the container for some URL that will be used in more that one container - is just a way to produce problems for yourselves. Just do not do so and check which container you open Google services and do authorization. So every container will have only that account related cookies.

Generally this is not related to this particular issue so I would like to stop this discussion here. :)

[achernyakevich-sc]

@dannycolin Looks like next week I will have free one of my developers familiar with Firefox Add-Ons development. Will it be ok if we will start implementation of new Confirmation Page according to mock-up I included to the issue description (be frankly it was created by manipulation of current page in dev-tools so all is implementable with minimal efforts)? What would be a chance to move this feature forward and include to upcoming releases?

[m-rieke]

Hi all, thanks for this great plugin for Firefox. Introducing this "Open this site in your assigned container" was really slowing down my work. I am logged in into several AWS accounts at the same time (with different containers) and always have to commit the change of containers.

So I suppose also to add an option like:

• Do not assign a specific container and always use the currently used one

Thanks!

[creative-resort]

@m-rieke in this case you can just remove the assignment from the container, that you've set it for, manually — once, and be good.

[creative-resort]

@dannycolin Are there any plans for addressing this issue? It's causing lots of unnecessary duplicate issues, that each need to be looked into. I almost posted one, myself.

[creative-resort]

@achernyakevich-sc Open in Current container and forget about assigned container would need to be set per container, right?

[achernyakevich-sc]

@achernyakevich-sc Open in Current container and forget about assigned container would need to be set per container, right?

As I can imaging currently MAC has the following implementation:

• user can set for the site+container pair that the site should be always open in the container.
• Confirmation UI for setting this pair will be shown after setting this pair and until user will explicitly confirm to do not ask anymore (checkbox).

If feature will be implemented as describer then selection of the Open in Current container and forget about assigned container will cause destroying of this pair - there will be no more automatic assignment of the container for the site and as result no displaying of Confirmation UI anymore.

[creative-resort]

will cause destroying of this pair

Oh, that would be bad. What I'd actually want is:

• Keep the site assigned to its container
• just don't ask about it inside of this container any more.

The dropdown option would be: Open in current container and remember this choice for this container and site

I would make your suggestion clearer with: Open in Current container and unassign site from its container

[achernyakevich-sc]

Sorry, "destroying" is bad word. In reality it is exactly "unassignment".

So I would agree that your label is matching better for the actions that will happen. :)

[bvanelli]

If you, like me, are here because this prompt appears every single time, for every single container, no matter what you answer in the box, then there is a hacky workaround. Simply delete the container preferences database:

On Mac, it's located somewhere like:

/Users/<your user here >/Library/Application Support/Firefox/Profiles/<your profile>/storage/default/moz-extension+++<your extension uuid>

You can get the extension UUID to show on the url, when you get the prompt again.

Just delete the idb, restart firefox and go through the extension setup again. Your containers and cookies should be preserved, as far as I tried.

[cornfeedhobo]

I would like to toss in my $0.02: drop downs are a terrible UX when the selection list has a clearly defined scope. Does anyone see the options expanding beyond those 4? If not, I really think the choice of a drop down should be reconsidered. Simply put, this adds more clicks, and that is always a negative.

[panzli]

I have the same UI problem, it would be really useful to have a keyboard shortcut for "reopen This Site in" or swap the button in the link adressbar to reopen in new container instead always opening.

[tactipus]

any headway recently?

[antipodes5]

Also came here to write up this issue in a fresh entry, then saw this. Very interested in progress.

@cornfeedhobo

I really think the choice of a drop down should be reconsidered.

I agree. Fiddly, ironic with something that's making the addon less fiddly.

Why not just have the options all there with radio buttons, no dropdown? One click magic and it goes away...