Re: Mutation events replacement

On Tue, Jul 5, 2011 at 2:23 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> That's a pretty fuzzy concept when
> http://wiki.ecmascript.org/doku.php?id=harmony:generators are involved, say.

Yes, granted, there will be corner-cases.  I don't know enough about
ES5 (let alone Harmony) to have an informed opinion on how much effort
it would be to address the corner-cases.  But *if* authors would be
given the ability to suspend mutation events, in the model Jonas
proposed, something like I described seems like the way to do it.
Explicit suspend/restore calls are clearly much worse -- they fail
even in the regular case if the author forgets the restore call.
Maybe we don't want to give authors the ability to suspend mutation
events at all, though, sure.

> 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.  This doesn't seem prohibitive by itself,
particularly given that functions where you'd use this will be doing
multiple DOM modifications.

> 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).

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.  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.

> 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

I'm not familiar enough with the specs or implementations on this
issue to answer tricky questions, though.  I'm following along because
this is relevant to some specs I edit, but I'm not going to be
involved in speccing the new mutation listener system itself.

Received on Tuesday, 5 July 2011 20:26:10 UTC