Re: Mutation events replacement

On 7/5/11 4:25 PM, Aryeh Gregor wrote:
> Maybe we don't want to give authors the ability to suspend mutation
> events at all, though, sure.

Indeed.

>> It would also be a good way to deoptimize jits (e.g. you have to actually
>> _have_ the function around to detect when it "exits", so if your jit does
>> inlining you have to turn that off or instrument it for functions that
>> contain that call) without realizing it.
>
> You'd have to add some extra instructions at every exit point of the
> function when you inline it, yes.  You'd have to do the same if you
> don't inline it, too.

Not necessarily; in the non-inlining case, removing the stack frame can 
just automatically do the work.

Unless you tail-recurse, in which case you don't remove the stackframe, 
of course....

> This doesn't seem prohibitive by itself, particularly given that functions where you'd use this will be doing
> multiple DOM modifications.

Maybe.  Maybe not.

> As far as I can see, the page can get repainted (meaning visually
> updated in response to DOM changes, not sure if my terminology is
> correct) in most browsers even when regular old scripts are running.
> When I write tests in JavaScript that do many seconds of DOM
> manipulation and add results to a table as they go, IE/Firefox/Opera
> all visibly start displaying results long before the tests are done
> running.

Unless your tests are explicitly yielding via setTimeout, that's quite 
odd in at least the Firefox case.

> But they probably don't want to do this in the middle of
> execCommand() execution, when the DOM is in some transient state that
> will display oddly for a moment and then flicker away.

It's not "a moment" if something happens in the middle of the 
execCommand that takes a while to complete and hits the network in the 
process.

The goal would be to not have such things happening in the middle of 
execCommand.

>> So if halfway through the mutation listeners for an execCommand one of the
>> listeners does a showModalDialog(), should the page the dialog comes from
>> stop painting until that dialog is dismissed?
>
> I wouldn't say so, no.  HTML5 seems to say that things like that
> should cause the UA to "pause", and the definition of that includes
> updating the rendering:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#pause

OK, that much I agree on.  But then I can't tell what you're proposing.

-Boris

Received on Tuesday, 5 July 2011 20:53:43 UTC