1289130 - Containers with really long identity name break the UX

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Jonathan Kingston [:jkt] he/him]

Attachment: Selection_248.png

We should probably truncate the input at some point. All the other UX seems to work however besides the URL bar when made smaller.

Either that or the URL should take precedence.

Comment 1

[Tanvi Vyas[:tanvi]]

Maybe we should have a maxlength for container names.  But how should we determine it?  Should it be based on screensize?  Or standard - ex: 20 characters?

Comment 2

[Bram Pitoyo [:bram]]

As a user, you can of course name a container to be as long as you like.

The menu can display this long name up to 59 character at the start and another 59 character at the end, with an ellipsis character (…) in the middle. Example: https://s3.amazonaws.com/f.cl.ly/items/343Y05213S152c2g000q/long-bookmark.PNG

But on the URL bar, space is limited, so I advise picking a sensible default value there. Let’s say 25 characters. Anything further, we’ll put an ellipsis at the end.

So, for example, we’ll get something like:
“University, high school a…”

That’s 25 characters plus ellipsis.

What do you think?

Comment 3

[Jonathan Kingston [:jkt] he/him]

I was going to suggest fixing this with the create containers just limiting to 20 even? We may need to truncate in the URL bar at some point however it certainly makes it more reasonable limiting it there right?

Comment 4

[Bram Pitoyo [:bram]]

That sounds even better. In the new container creation dialogue, we can limit text entry to x number of characters. That way, there’s no way for user to type in names that are too long.

Comment 5

[Jonathan Kingston [:jkt] he/him]

I set the maxlength to 20: https://bugzilla.mozilla.org/show_bug.cgi?id=1267916#c27 This fixes it down to smaller than the browser will be before Help gets hidden in the top bar.

Is this enough?

Comment 6

[Tanvi Vyas[:tanvi]]

Limiting input sounds good.  I think Jonathan said he limited to something around 120 characters.  I think something around 30 would be better.  Jonathan said he did some resizing to figure out what a good count was, but I can't remember what it was.  I think he can figure this out, if he hasn't already.

Thanks!

Comment 8

[Itiel]

I don't think limiting the container name is the right approach.
As I've said in bug 1329456, I think it'd be a good idea to limit the container name's length on the URL bar (proportional to the URL bar's width, about 20%-30% maybe?), and in case it's too long for the URL bar to handle, show a tooltip with the container's full name when hovering it in the URL bar.

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Comment 11

[Danny Colin [:sdk]]

Attachment: WIP: Bug 1289130 - Containers with really long identity name break the UX

Comment 12

[Danny Colin [:sdk]]

I don't think limiting the container name is the right approach.

Looking at it today a bit more, I now agree with Itiel. There's a few issues with enforcing a maxlength as a solution:

1. It'll most likely affect different locales than english a lot more especially if the limit is 30 chars.
2. Even 30 chars use more than half of the urlbar before we hit the rule to completely hide the label when the window width is lower than Nth pixels.
3. Applying a limit in the chrome or in about:preference#containers won't prevent an addon using the ContextualIdentities API to create a container with more than 30 characters long name. I don't think we want to apply this limit directly on the API itself either.

Based on that, Itiel proposition to visually truncate the container name label seems like the right approach. We should enforce a max percentage that the label can use and be a little more aggressive in applying the rule that completely hide it when the window width is reduced (See 2). The container icon is still present whatever the width is and you can hover over to show a tooltip containing the name. This should be enough for the user to know in which container they are especially that I'm guessing it's pretty rare for users to have a window small that half the screen width.

Comment 13

[Frederik Braun [:freddy]]

Looks like this hasn't seen a lot of attention but is still worth fixing.
I want to point out that a hover over the container slip will give you the full name. A visual restriction sounds fine, as it would still give the ability to view the full string. Risk is furthermore limited as the container information is always user supplied (modulo defaults and translations).

Are you still interested in pursuing this, Danny?

Comment 14

[Danny Colin [:sdk]]

Yes, I'm still interested. I don't know if it's enough to simply visually hide the text when the name is too long. It might make it looks like the UI is broken since the hiding mechanism isn't tied up to a user interaction (e.g. reducing the window width).

As I already pointed out, dynamically hiding it (e.g. full name > 30 chars > fully hidden) is also a bit tricky since in some cases even 30 chars is long enough to visually break things.

:freddy do you have any suggestion? Should we ask the UX team?

Comment 15

[Frederik Braun [:freddy]]

I could imagine us assigning a max-width of some size and using text-overflow: ellipsis to indicate that there's text missing.
I've asked around internally to ensure that we're not missing some obvious widely used internal pattern that we can simply adopt by adding a smart class attribute or such.

What I can say from staring at searchfox for a bit is that ellipsis is the more widely used value (in comparison to fade).

Comment 16

[Danny Colin [:sdk]]

Attachment: Bug 1289130 - Limit width of container indicator label in urlbar r=mconley

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eb8924396606
Limit width of container indicator label in urlbar r=mconley,desktop-theme-reviewers,tabbrowser-reviewers,emilio

Comment 18

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/eb8924396606