"focused & collapsed" state is still used when selecting text in previously unfocused megabar
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: dao, Assigned: dao)
References
Details
Attachments
(1 file)
|
||
Comment 1•5 years ago
•
|
||
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.
|
Assignee | |
Comment 2•5 years ago
|
||
|
|
Assignee | |
Comment 3•5 years ago
|
||
I believe the original motivation was a bit more complex, because the megabar obscured potential drag targets. It mostly doesn't do that anymore. We also don't actually know that the user will want to copy part of the URL, they may want to type and replace it. Last but not least, the code I'm removing doesn't even work on Linux.
|
|
||
Comment 4•5 years ago
|
||
Fair enough. r+
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d8b46812ad8a Expand the megabar regardless of text selection. r=harry
|
||
Comment 6•5 years ago
|
||
| bugherder | ||
Description
•