Open Bug 1289130 Opened 8 years ago Updated 2 years ago

Containers with really long identity name break the UX

Categories

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

defect

Tracking

()

Tracking Status
firefox57 --- fix-optional

People

(Reporter: jkt, Assigned: sdk, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [userContextId][domsecurity-backlog])

Attachments

(2 files)

Attached image Selection_248.png (deleted) —
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.
Depends on: 1267916
Whiteboard: [userContextId][domsecurity-backlog]
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?
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?
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?
Flags: needinfo?(tanvi)
Flags: needinfo?(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.
Flags: needinfo?(bram)
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?
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!
Flags: needinfo?(tanvi)
Priority: -- → P3
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.
Severity: normal → S3
Assignee: nobody → contact

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.

Flags: needinfo?(itiel_yn8)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: