Suggested severity

• S2

Affected versions

• Fx84.0a1
• Fx83.0b2

Affected platforms

• Windows 10
• Ubuntu 18.04
• macOS 10.13

Steps to reproduce

1. Launch Firefox.
2. Navigate to www.google.com and bookmark the page.
3. Open a new tab and type 'g' in the address bar.

Expected result

• The tab to search animation plays without issue.

Actual result

• There's a settings wheel being played out along with the tab to search animation.

Regression range

• This is not a new regression.

Additional notes

• This is more obvious if you look at the right side of the drop-down as you're typing 'g'.

I stepped through the frames of this video, and there's no settings wheel being animated in. What's happening is that the heuristic result is the only result for two frames and so the settings wheel is immediately underneath. When the tab-to-search result finally pops in, your brain interpolates the settings wheel and the tab-to-search result being in the same frame. I attached a screenshot of the first four frames after "g" is typed.

The tab-to-search animation does make the address bar view more visually busy. We could talk to UX about altering the timing of the animation to alleviate this.

I think UX already wanted to make the animation a little bit delayed because too many things move at once. We could probably slow down the beginning of the animation, or just delay it.

We spoke with UX and we decided to add 50ms delay to this animation. I think it might be a better idea to play around with 75-85 ms delays. That way it only starts animating after results start coming in (in most cases).

100ms is a point at which most results have populated for most people, according to Telemetry. Adding this delay reduces the amount of motion at any given point in the Urlbar. This also has the nice added benefit of not showing the animation for people typing an unrelated query who type at least moderately quickly. For example, if "amazon.com" is autofilled when the user types "a", but they're typing "apple", we don't show the animation if they type "ap" in <100ms.

Telemetry suggests this delay could be as short as 75ms and still be effective, but 100ms seemed like a nice compromise between making the delay as long as possible and not playing an animation well after the user stops interacting with the Urlbar.

Depends on D95174

A video comparing the delay with the current behaviour (23.6MB): https://drive.google.com/file/d/1dw4DIoseOv_UHg7__qg2GgKijV0tcx2t/view?usp=sharing

https://hg.mozilla.org/mozilla-central/rev/9c9e4948dd3b

The patch landed in nightly and beta is affected.
:harry, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9184573 [details]
Bug 1672701 - Add a 100ms delay to the tab-to-search animation. r?adw,ntim

Beta/Release Uplift Approval Request

• User impact if declined: We would show too much motion at once for some searches in the address bar. This is also part of the search mode feature launching in 83.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): CSS-only
• String changes made/needed:

Comment on attachment 9184573 [details]
Bug 1672701 - Add a 100ms delay to the tab-to-search animation. r?adw,ntim

Low risk as it only changes the duration of a CSS animation and part of a 83 feature, uplift approved for 83 beta 8, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/5e1002daf369