As noted here: https://groups.google.com/forum/#!topic/mozilla.dev.tree-alerts/MkctEZYELQU bug 1128354 caused a 2-3% regression in Talos "Customization Animation Tests". It's not entirely surprising that this patch had a perf impact somewhere. Basically, it was partially-suppressing an optimization (from bug 1054010) that was being applied too broadly & breaking correctness in some cases. (Specifically, we can't apply bug 1054010's optimization when there's a percent-height element inside of a flex item.) It may be worth investigating the CSS Flexbox usage that's getting exercised by these "Customization Animation Tests", to see if we can optimize the CSS such that it doesn't trigger the unoptimizable path here. (In particular, if there are percent-height elements inside of flex items, we should consider removing those, or tweaking those flex items with a fixed min-width and/or flex-basis so they don't require a "measuring" reflow.)

Bug 1145868 (a customize-mode mis-rendering, fixed by bug 1128354) may be a hint at which pieces of customize-mode UI could be tweaked to improve perf here.

Not sure if this is helpful, but I traced that the regression specifically seems to occur in the customize-enter-css subtests with perfherder: http://wrla.ch/blog/2015/03/perfherder-update-summary-series-drilldown/

Thanks, wlach! That's definitely helpful. avih says "customize-enter-css" measures performance during the "screen shrink" animation, when you enter customize mode. We seem to update the layout on each frame of the animation, and it makes sense that bug 1128354 could've made those updates more expensive, as discussed in comment 0. Anyway, we need to see what piece of content is triggering extra reflows as a result of bug 1128354, and then we probably want to see if we can tweak that content so that it no longer needs to trigger those extra reflows. (e.g. by removing a percent height)