<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-05-11 20:53 GMT+02:00 Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If we can get reflows in these key interactions under control, post-57,<br>
it might be worth investing time and resources into getting non-key<br>
interactions under control as well. Then, perhaps, it'd be worth looking<br>
at bigger hammers.<br>
<br>
Here's a bigger hammer: suppose we had a function on Components.utils<br>
that, when called, essentially meant "anything in this JS scope can<br>
cause us to flush layout". We'd then put this function in all remaining<br>
JS code where we currently force a flush. If flushes occur without that<br>
function having been called in that scope, we throw. At this point,<br>
we've effectively created a whitelist that we can then start to whittle<br>
down. That's exactly the same play we used to remove unsafe CPOWs from<br>
our front-end code.<br></blockquote><div><br></div><div>FWIW, a reflow in random UI code doesn't necessarily mean that the UX is bad in any perceivable way. See for instance <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1364360">https://bugzilla.mozilla.org/show_bug.cgi?id=1364360</a> that I wontfixed as I don't think a <1ms reflow in secondary UI this is worth spending time on. If we can get smart APIs to avoid reflows automatically, that would be great, but lacking that, throwing exceptions and requiring explicit opt-in seems overzealous.</div><div><br></div><div>dao<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the other side of the coin is providing tools that make doing the<br>
right thing easier. Perhaps we should write or adopt a library for our<br>
front-end code like FastDOM[2] that makes it simpler to know where it's<br>
safe to query layout / style, and when it's safe to dirty the DOM.<br>
<br>
Anyhow, these are ways machines could potentially help us.<br>
<br>
-Mike<br>
<br>
[1]: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1354194" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1354194</a>,<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1363505" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1363505</a> and<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1363507" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1363507</a><br>
[2]: <a href="https://github.com/wilsonpage/fastdom" rel="noreferrer" target="_blank">https://github.com/wilsonpage/<wbr>fastdom</a><br>
<span class="gmail-im gmail-HOEnZb"><br>
On 2017-05-08 6:16 PM, Gregory Szorc wrote:<br>
> On Mon, May 1, 2017 at 2:32 PM, Mike Conley <<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a><br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">> <mailto:<a href="mailto:mconley@mozilla.com">mconley@mozilla.com</a>>> wrote:<br>
><br>
>     Hello folks,<br>
><br>
>     Over the course of several weeks, I've been slowly accumulating<br>
>     information on best practices and tips to help us front-end<br>
>     engineers write code with lower risk for introducing jank to the user.<br>
><br>
>     I've published that information here:<br>
>     <a href="https://developer.mozilla.org/en-US/Firefox/Performance_best_practices_for_Firefox_fe_engineers" rel="noreferrer" target="_blank">https://developer.mozilla.org/<wbr>en-US/Firefox/Performance_<wbr>best_practices_for_Firefox_fe_<wbr>engineers</a><br>
>     <<a href="https://developer.mozilla.org/en-US/Firefox/Performance_best_practices_for_Firefox_fe_engineers" rel="noreferrer" target="_blank">https://developer.mozilla.<wbr>org/en-US/Firefox/Performance_<wbr>best_practices_for_Firefox_fe_<wbr>engineers</a>><br>
><br>
>     I was originally collaborating with a few people on it in a Google<br>
>     Doc, but it's stabilized enough now to post on MDN. Do feel free to<br>
>     continue to add tips (or corrections!).<br>
><br>
><br>
> Thanks for putting this together, Mike!<br>
><br>
> This isn't discrediting your excellent work. But I feel like I need to<br>
> ask a question: how do we have machines identify when best practices<br>
> aren't being followed? After all, machines will catch the failures<br>
> they're taught to catch 100% of the time, which is better than human<br>
> code review will do. Would it be possible to have features (possibly<br>
> limited to debug builds) that detect when bad patterns are being used<br>
> and raise warnings or errors? Or for things like detecting synchronous<br>
> flushes we could have the test harness automatically record the count<br>
> and annotate certain tests with an allowed value (kind of like how<br>
> reftest expectations work). Obviously some patterns are hard or<br>
> impossible to codify. But *anything* that we teach machines to catch for<br>
> us is one less thing for humans to worry about and inevitably miss<br>
> during code review.<br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div></div>