This is one of those things that unfortunately didn't make it out of Slack. From #search: > harry: @verdi The new spec removes the focused & collapsed state but there’s one case I’m still curious about. A while ago, you said that we shouldn’t expand if the user selects part of the URL. This was to avoid unnecessary motion for a simple copy action. Should that stay in? I tested it on a build that has the focused & collapsed state removed and it doesn’t appear to cause the same engineering headaches as the old focused&collapsed behaviour since we just use it in the one case. I’m wondering how you would weigh the usefulness of not expanding for partial selection versus having this focused&collapsed state in only one specific case > verdi: @harry I like it. It seems unnecessary to expand if we can tell you're really just copying a part of a url.
Bug 1599792 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is one of those things that unfortunately didn't make it out of Slack. From #search on November 5: > harry: @verdi The new spec removes the focused & collapsed state but there’s one case I’m still curious about. A while ago, you said that we shouldn’t expand if the user selects part of the URL. This was to avoid unnecessary motion for a simple copy action. Should that stay in? I tested it on a build that has the focused & collapsed state removed and it doesn’t appear to cause the same engineering headaches as the old focused&collapsed behaviour since we just use it in the one case. I’m wondering how you would weigh the usefulness of not expanding for partial selection versus having this focused&collapsed state in only one specific case > verdi: @harry I like it. It seems unnecessary to expand if we can tell you're really just copying a part of a url.