Bugzilla

STR:
 0. Install profiler from https://profiler.firefox.com/
 1. Visit about:blank.
 2. Ctrl+Shift+1 to start profiling.
 3. Ctrl+T to open a new tab.
 4. After a few seconds, Ctrl+Shift+2 to stop profiling.

ACTUAL RESULTS:
Profile shows a red bar for a period of jank, which includes some flexbox layout.  In particular, there are some script-triggered sync reflows from an IntersectionObserver callback which checks `.clientWidth`, which I suspect are associated with image lazy-loading.

EXPECTED RESULTS:
I suspect the series of short script/IntersectionObserver-triggered reflows should probably be cheap or free, because layout is probably not changing much.  I'm not sure whether the tiles are styled such that we can theoretically infer that the flex containers involved don't need to reflow, or if there's styling that we would need to add (along with optimizations) to reliably get that result -- but one way or another, we should try to be sure that no serious reflow work needs to happen after the initial layout.

Also/alternatively, perhaps the about:newtab coad shouldn't be reading clientWidth in the IntersectionObserver callback, since that forces any of the callback's earlier restyling to be immediately flushed. We're probably not coalescing these multiple IntersectionObserver-callback-invocations' restyling at all right now, due to the fact that they're doing this flush.

Here's a profile I captured of the STR:  https://perfht.ml/2SWyogu
The series of 9 reflows (each 2-3ms long) after timestamp 1.64s are the ones that I'm primarily concerned with improving/avoiding.

STR:
 0. Install profiler from https://profiler.firefox.com/
 1. Visit about:blank.
 2. Ctrl+Shift+1 to start profiling.
 3. Ctrl+T to open a new tab.
 4. After a few seconds, Ctrl+Shift+2 to stop profiling.

ACTUAL RESULTS:
Profile shows a red bar for a period of jank, which includes some flexbox layout.  In particular, there are some script-triggered sync reflows from an IntersectionObserver callback which checks `.clientWidth`, which I suspect are associated with image lazy-loading.

EXPECTED RESULTS:
I suspect the series of short script/IntersectionObserver-triggered reflows should probably be cheap or free, because layout is probably not changing much.  I'm not sure whether the tiles are styled such that we can theoretically infer that the flex containers involved don't need to reflow, or if there's styling that we would need to add (along with optimizations) to reliably get that result -- but one way or another, we should try to be sure that no serious reflow work needs to happen after the initial layout.

Also/alternatively, perhaps the about:newtab coad shouldn't be reading clientWidth in the IntersectionObserver callback, since that forces any of the callback's earlier restyling to be immediately flushed. We're probably not coalescing these multiple IntersectionObserver-callback-invocations' restyling at all right now, due to the fact that they're doing this flush.

Here's a profile I captured of the STR, using current Nightly: https://perfht.ml/2SWyogu (filtered for nsFlexContainerFrame)
The series of 9 reflows (each 2-3ms long) after timestamp 1.64s are the ones that I'm primarily concerned with improving/avoiding.

STR:
 0. Install profiler from https://profiler.firefox.com/
 1. Visit about:blank.
 2. Ctrl+Shift+1 to start profiling.
 3. Ctrl+T to open a new tab.
 4. After a few seconds, Ctrl+Shift+2 to stop profiling.

ACTUAL RESULTS:
Profile shows a red bar for a period of jank, which includes some flexbox layout.  In particular, there are some script-triggered sync reflows from an IntersectionObserver callback which checks `.clientWidth`, which I suspect are associated with image lazy-loading.

EXPECTED RESULTS:
I suspect the series of short script/IntersectionObserver-triggered reflows should probably be cheap or free, because layout is probably not changing much.  I'm not sure whether the tiles are styled such that we can theoretically infer that the flex containers involved don't need to reflow, or if there's styling that we would need to add (along with optimizations) to reliably get that result -- but one way or another, we should try to be sure that no serious reflow work needs to happen after the initial layout.

Also/alternatively, perhaps the about:newtab code shouldn't be reading clientWidth in the IntersectionObserver callback, since that forces any of the callback's earlier restyling to be immediately flushed. We're probably not coalescing these multiple IntersectionObserver-callback-invocations' restyling at all right now, due to the fact that they're doing this flush.

Here's a profile I captured of the STR, using current Nightly: https://perfht.ml/2SWyogu (filtered for nsFlexContainerFrame)
The series of 9 reflows (each 2-3ms long) after timestamp 1.64s are the ones that I'm primarily concerned with improving/avoiding.