Closed Bug 1599792 Opened 4 months ago Closed 4 months ago

"focused & collapsed" state is still used when selecting text in previously unfocused megabar

Categories

(Firefox :: Address Bar, defect, P1)

Unspecified
Windows
defect
Points:
1

Tracking

()

RESOLVED FIXED
Firefox 72
Iteration:
72.3 - Nov 18 - Dec 1
Tracking Status
firefox72 --- fixed

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.

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.

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.

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
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72
You need to log in before you can comment on or make changes to this bug.