Windows 10, latest m-c code. When the tresize test runs, it increases the window size from a starting size of 425x425, adding 2 pixels to the width and height in each iteration. There are 300 iterations. For the first <x> iterations (where x is at least 30 but less than 150), each resize is accompanied by the URL bar shifting position twice. It's like a jitter, but there are layouts/repaints involved so it is potentially expensive. You can observe this visually by just running a single iteration: ./mach talos-test -a tresize --cycles 1 and observing the left edge of the URL bar as the window resizes. To make it more obvious, modify the iteration count and timeout in tresize.js [1] to be 30 and 500, respectively. I don't know what effect fixing this issue will have on the tresize results, because of bug 1471961 the results are going to be kind of unpredictable. [1] https://searchfox.org/mozilla-central/rev/d47c829065767b6f36d29303d650bffb7c4f94a3/testing/talos/talos/startup_test/tresize/addon/content/tresize.js#13,23

It happens on macOS too, here's a video

I don't think this has anything to do with the urlbar, I would bet it's the customizableUI's handling of resize and {over,under}flow events that causes this. We made this code avoid sync flushes in bug 1447619, but the restyles are still expensive, just not triggered directly by the JS code.

Here is a profile of resizing the window in a way that makes toolbar items appear and disappear: https://perfht.ml/2vtqRLk This is on today's nightly with a new profile, on OS X. I just opened a window and resized it several times. Emilio, anything actionable in this profile?

Nothing particularly striking from the code. In particular, that's hitting the ResizeReflowIgnoreOverride shrink-to-fit path, which flushes there so we have proper viewport unit resolution: https://searchfox.org/mozilla-central/rev/f0c15db995198a1013e1c5f5b5bea54ef83f1049/layout/base/PresShell.cpp#1982 see bug 1430844. Do we need to pass the shrink-to-fit bit for this resize? If so we're pretty much doomed, that's kind of expensive. We could try to throttle the resizes somehow, but that may be more suitable for the frontend code? Not sure.

Hmm, or maybe it's hitting the flush right below it... We don't seem to be reflowing though.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4) > Nothing particularly striking from the code. One thing that was puzzling me when looking at the profile is that we seem to spend a fair amount of time in nsIDocument::FlushUserFontSet, and I don't see how resizing the window relates to fonts. But maybe that's just a red herring, and just happens to be the first thing causing us to flush style sheets.

Yeah, FlushUserFontSet is the first thing that calls UpdateStylist. If we're updating them it means that media queries have changed.

Just to check all the calls to UpdateStylist are for a reason :)

Nothing out of the ordinary there. I'll check if something else is dirtying the styles somehow.

Yeah, I only see rebuilds for new documents (like some svgs) and when the media queries actually change.