750892 - window.assertLayout(callback,[reflow, flush, etc]) aid

Status: NEW

(Core :: Layout, defect)

Description

[(dormant account)]

I'm not going with naming, but it would be extremely handy to have an api that guarantees that JS runs continuously without any implicit&expensive interruptions. callback would trigger a js exception when an expensive thing is triggered.
This would make it much easier to debug accidental expensive things.

Comment 1

[(dormant account)]

loading, reframing xbl should be in the list of expensive things to watch for

Comment 2

[Boris Zbarsky [:bzbarsky]]

The simplest thing to do here is probably to make nsDocument::FlushPendingNotifications (for the right sorts of flushes) and PresShell::FlushPendingNotifications bump some global counter.

Then what assertLayout can do is:

1)  Set the counter to 0.
2)  Call the callback function.
3)  Throw if the counter is nonzero when the function returns.

The alternative is to have the flush methods return error if called while some global boolean is set, but then we have to change all callers of those methods to deal.

The only drawback is a slight slowdown on no-op flushes, but I think it should be OK.

To support the optional argument we'd just use several counters, one per type of thing we care about.

Comment 3

[(dormant account)]

Can we do this at xpconnect(or dom binding?) level? ie set some xpconnect error flag so the property access is what fails(and points out what exactly is triggering the unwanted condition). Having the whole assert fail is less useful.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Doing it on the new DOM binding level is possible, at a slight perf hit to all calls.

Doing it in xpconnect is also possible, but a bit more of a pain....

Comment 5

[Boris Zbarsky [:bzbarsky]]

How would you feel about only doing the check in debug builds?

Comment 6

[(dormant account)]

(In reply to Boris Zbarsky (:bz) from comment #5)
> How would you feel about only doing the check in debug builds?

That'd be sufficient.

Comment 7

[(dormant account)]

(In reply to Boris Zbarsky (:bz) from comment #4)
> Doing it on the new DOM binding level is possible, at a slight perf hit to
> all calls.

do "new" bindings handle css/etc access already? Ie how long do we have to wait for this to become useful?

Comment 8

[Boris Zbarsky [:bzbarsky]]

New bindings only handle XHR now.  They'll soon handle canvas contexts and inline style.

So we should probably do this in xpconnect (and quickstubs) if we want it useful soon.  It might not actually be that bad, come to think of it.

So with this approach we want two global flags: a boolean for when we're under the assertLayout call, and a counter that gets zeroed in the binding before calling into C++ and gets checked in the binding after return from C++.