Should functions like getBoundingClientRect, getComputedStyle etc trigger an update?

[rakina]

If we call functions like getBoundingClientRect() on a locked element, should they trigger an update to the element and return the newly calculated values? If not, should they always return the value when the element got locked? What if there's already an update() call previously?

It seems like some things like DevTools might need the old/currently-painted values.

cc @fergald @chrishtr @vmpstr

[chrishtr]

These methods should force a lifecycle update for the document, and also force all of the work
that happens in update(), but not force a commit().

The definition of the methods like getBoundingClientRect in this situation are not defined precisely yet, but I propose that getBoundingClientRect return a rect relative to the ancestor element that holds the lock. If multiple such ancestors hold a lock, then the nearest one.

Agree that DevTools probably wants the old/currently-painted ones.

[chrishtr]

Also, in lock-after-append mode, calling the methods on the locked root should force outer layout
up to and including that element, but not the locked subtree.

[ojanvafai]

Alternate proposal: APIs that need to crawl up the ancestor chain (i.e. positioning APIs) throw or return invalid return values (e.g. undefined). Making them relative to the locked ancestor seems like it will lead to more bugs.

In this world, things like offsetHeight, getComputedStyle, etc work fine, but offsetTop, getBoundingClientRect, etc would throw.