Which strategy for preventing infinite loop when delivering resize notifications?

[atotic]

We'd like to change to using "Depth limit" instead of "Numeric limit".

Discussion

The ResizeObserver API delivers its notifications in a loop:

resizeNotifications = observer.detectResizes()
while (resizeNotifications)
   observer.notifyHandlers(resizeNotifications)
   resizeNotifications = observer.detectResizes()

This loop can go on forever, as long as resizeHandlers are resizing other elements. Lets call resizeHandler causing further resize notifications a resize cascade.

resizeHandlers are expected to be moving/showing/hiding DOM elements, so the risk of infinite loops is real.

This infinite loop needs to be broken because frozen UI is a bad UI. A page whose loop is broken would probably feel sluggish, because it is performing extra paints; janky too, because it is displaying partially formatted page.

How do we break out of the loop?

1. Numeric limit

Numeric limit is what we have in the current spec. The loop is limited to at most N iterations. The constant N is TBD. The group consensus was to make it large, 32 or 64.

pros: simplicity, consistency
cons: limit is arbitrary.

2. Depth limit

Depth limit works by narrowing down the set of nodes allowed to receive notifications in each iteration.

Let N be set of all observed nodes
while (N is not empty)
  resizeNotifications =  observer.detectResizesInSet(N);
  observer.notifyHandlers(resizeNotifications);
  let d be the depth of the shallowest node in N
  remove all nodes with depth <= d from N

Depth limit can iterate at most 'depth of DOM tree' times.

A nice property of depth limit is that if a resizeHandler generates new notifications, only its children get to handle them right away. This is what you want to see in a layout algorithm, a one-way propagation of constraints from top to bottom. The unbound propagation is usually a mistake.

We prefer depth limit to numeric limit because it nudges developers towards creating performant layouts.

3. Time limit

Time limit sounds promising: loop until at most LIMIT milliseconds have passed. The problem is that this does not give developers any guarantees at all how many times loop can be executed. On low-end phones, a single iteration might be all they get.

[atotic]

Depth limit strategy was added to the spec.