1626757 - Pause on uninterruptible reflow with Event Breakpoints

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[:Harald Kirschner :digitarald]

Sync uninterruptible reflows are the bane of developers, even those who work on Firefox (see https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers#Detecting_and_avoiding_synchronous_reflow), and mainly debuggable right now with profiling.

Having a new event (aka "system") breakpoint that lets developers pause in the code that causes these reflows (before they are being applied), allows to debug the app state and logic flow. The debugger also allows logging for those events, which could allow to add more meta-data on specifics that cause the layout.

Exposing this as logging option to other parts of the frontend where layout-related work happens would be great; where bug 1599353 could do a lot more for general reflows (also not-JS causes).

Comment 1

[Emilio Cobos Álvarez (:emilio)]

You mean pausing on the DOM mutation that causes a reflow? That doesn't seem quite trivial.

If your dom mutation is toggling an attribute which ends up changing a CSS property, which ends up causing a reflow, we only know we're going to do a reflow once we're done with styling.

Comment 2

[:Harald Kirschner :digitarald]

If knowing early is a hard problem, could we reduce scope by pausing after the mutation that caused the reflow?

Comment 3

[Logan Smyth [:loganfsmyth]]

@Emilio Would you be able to point us toward the code where a reflow is triggered in style change/query? It would make life easier for figuring out how feasible this would be.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

So, my question in comment 1 maybe wasn't quite correctly phrased. Let's say you have a page that does this, with clean layout / style.

div.classList.add("foo");
div.getBoundingClientRect();

If .foo causes a style change that would cause a reflow, then getBoundingClientRect() would do a sync uninterruptible reflow. Is the intention of this bug to pause on the getBoundingClientRect() call, or on the classList.add call?

The first one is trivial, and you don't even need any layout support for that, I think. We already have weak reflow observers which allow you to observe uninterruptible reflows.

The second one is the one that's non-trivial. The most usual reflow is triggered by the style code in here, but that happens already too late after the DOM mutation.

Comment 5

[:Harald Kirschner :digitarald]

The first one is trivial, and you don't even need any layout support for that, I think. We already have weak reflow observers which allow you to observe uninterruptible reflows.

Thanks a lot for the details, Emilio. As this is causing the reflow it should be where the Debugger pauses. Untangling which style change caused the reflow is something we can leave to the developers; but follow up work could maybe expose more insights from the platform around that.