This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html "Delivery of MutationRecords happens asynchronously, at the end of the current “microtask”. This is between Options 2 and 3 from this discussion http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html. Instead of calling listeners at the end of outermost DOM operation or at the end of a Task, listeners are called at the end of outermost script invocation. If there are no script invocations, listeners are called at the end of Task." See http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-observers for the current language. Specifically, "delivery" above means "invoking the MutationCallback associated with a registered observer" passing it the current "record queue" of that observer, and clearing the queue (just before invocation).
I don't understand which observers I'm supposed to know to call. Can you elaborate? It would be ideal if there was just an algorithm I could call with a browsing context, Document, event loop, or other generic grouping identifier that would just fire all the relevant observers.
I don't think HTML spec should define when MutationObservers callbacks run, but it should define what a microtask (feel free to change the name) is, and what it means to run something at end of microtask. Then DOM 4 could use that to define when callbacks are called.
In reply to comment #2, As I mentioned on IRC earlier, we do not want DOM to depend on HTML. I defined http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-invoke as a hook for HTML. You also need to define the scope of "scripting environment", which is basically all browsing contexts that can reach each other via script, but I cannot mention that normatively in the DOM. (At least until we give up on this dependency exercise.) There is still an XXX comment remaining the source regarding transient observers and all this, advice welcome.
Oh yes, and the million dollar question, what about garbage collection?
(In reply to comment #4) > Oh yes, and the million dollar question, what about garbage collection? Not sure exactly what you're asking about, but the records would normally be GCed after the last observer with that record in its queue has been called (unless of course the observers take their own references). Which implies that the nodes referred to by those records would also be collectable (if they're no longer in the document or referred to elsewhere). As for the MutationObserver instances themselves, the WebKit approach is to give them weak references to the nodes they observe: if the node is collected, and there are no more references to the observer, it can also be collected.
For GC, I recommend just saying that the EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see http://html5.org/tools/web-apps-tracker?from=7008&to=7009 Rationale: Concurred with reporter's comments.
1. You use both <var title="">running mutation observers</var> and <dfn>running mutation observers</dfn> 2. Still curious about what you wanted to say about GC :-)
1. Fixed. 2. I didn't have anything to say. I thought I should, so I wrote what you saw, then I thought about it, and realised I had nothing useful to say. So then I deleted what I wrote. Except apparently I didn't. :-) EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r7019. Check-in comment: fix up some xrefs http://html5.org/tools/web-apps-tracker?from=7018&to=7019
Checked in as WHATWG revision r7020. Check-in comment: more markup errors http://html5.org/tools/web-apps-tracker?from=7019&to=7020