<div dir="auto">This is amazing, thank you for all the hard work on this feature!</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 24, 2018, 21:11 Mike Conley <<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
Tab warming is a perceived performance optimization where we render and<br>
upload layers for a tab when hovering that tab with the mouse, to<br>
optimize for tab switching when the user actually clicks a mouse button.<br>
<br>
Since bug 1423220[1], this optimization has been enabled on the Nightly<br>
channel for almost all of the 61 Nightly cycle. Telemetry has<br>
confirmed[2] a nice drop in the mean and median time between users<br>
requesting a tab switch, and users being presented with the contents of<br>
the requested tab. We've also seen a nice drop in the number of users on<br>
our Nightly channel that see tab switch spinners[3].<br>
<br>
Since baking on Nightly, only one major behavioural glitch has been<br>
reported[4] (and subsequently fixed).<br>
<br>
Bug 1453080[5] tracks a regression where warming can cause animations in<br>
the tab strip on macOS to seem sluggish.<br>
<br>
Considering that tab switching, tearing and re-ordering is something our<br>
users do every day, I'm quite confident that simply existing on Nightly<br>
has given us decent testing coverage. I therefore intend to land a patch<br>
in bug 1456602[6] later this week (before the soft freeze begins) to let<br>
tab warming ride the trains out to release on the 61 train for Windows<br>
and Linux. Warming will continue to be enabled on Nightly for macOS, but<br>
will be restricted to Nightly for now, until we can get bug 1453080 sorted.<br>
<br>
Disabling the optimization, should the need arise, is trivial[7], but I<br>
hope it doesn't come to that.<br>
<br>
Do let me know if you have any concerns. Thanks!<br>
<br>
-Mike<br>
<br>
[1]: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1423220" rel="noreferrer noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1423220</a><br>
[2]: <a href="https://mzl.la/2HLltea" rel="noreferrer noreferrer" target="_blank">https://mzl.la/2HLltea</a><br>
[3]: <a href="https://mikeconley.github.io/bug1310250/" rel="noreferrer noreferrer" target="_blank">https://mikeconley.github.io/bug1310250/</a> - "Affected client %".<br>
Sorry for the noisy graph / crowded labels. March 13th is when the<br>
optimization was first detected.<br>
[4]: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1447193" rel="noreferrer noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1447193</a><br>
[5]: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1453080" rel="noreferrer noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1453080</a><br>
[6]: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1456602" rel="noreferrer noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1456602</a><br>
[7]: The optimization is controlled via the<br>
browser.tabs.remote.warmup.enabled pref.<br>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank" rel="noreferrer">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div>