W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 05 Jul 2011 14:23:23 -0400
Message-ID: <4E13569B.9040801@mit.edu>
To: public-webapps@w3.org
On 7/5/11 12:30 PM, Aryeh Gregor wrote:
> Why not have a function like suspendMutationEvents() that just makes
> the current JavaScript function a compound mutating function?  That
> is, when you call that function, all mutation events are suspended
> until the function exits.

That's a pretty fuzzy concept when 
http://wiki.ecmascript.org/doku.php?id=harmony:generators are involved, 
say.

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.

> but it should work fine in principle, right?

"maybe".  ;)

> I'm inferring from other posts in the thread that this is specifically
> because they want to be able to respond to mutations before the
> document is repainted or becomes responsive to user interaction.  Is
> this right, or are there other reasons it can't be fully async?
> Specifically, could we make a new "pre-event loop" that runs right
> before the regular event loop, therefore before the page responds to
> user input but after the currently running script has completed?

The page can get repainted before the currently running script has 
completed: think sync XHR or alert() calls.  Note that the event loop 
will run in those cases too, in some UAs; not sure what the spec says 
about it right now (or even whether what the spec says is web-compatible).

> If it turns out one of the constraints here is that we want mutation
> events to finish before the page is repainted, we should explicitly
> specify that UAs must not update the display of the page due to DOM
> mutations between the time when a compound mutating function starts
> running and when all corresponding mutation handlers have run, or
> something like that.  That makes sense: we don't want the page to be
> repainted halfway through an execCommand() execution anyway, for
> instance.

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?

-Boris
Received on Tuesday, 5 July 2011 18:23:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT