[Bug 16606] New: MutationObserver doesn't provide a safe way to suspend & resume observation

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16606

           Summary: MutationObserver doesn't provide a safe way to suspend
                    & resume observation
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM
        AssignedTo: annevk@opera.com
        ReportedBy: rafaelw@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org


It's a common use to want to have the mutation callback not report any changes
it makes in the following invocation. This is trivially accomplished by calling
disconnect() at the beginning of the callback and observe() immediately before
exiting.

disconnect() clears any queue records, but this is safe inside a mutation
callback because the observer has just been delivered all mutations and is
guaranteed that no other actor could have made new ones.

However, if the observer would like to ignore changes which are made outside
the mutation callback (say in response to a XHR callback), suspending
observation by calling disconnect/observe risks losing mutation records already
queued.

[This came up via a user of the MutationSummary library whose use case is
synchronizing a JSON structure with DOM. The problem arises when trying to
ignore changes made by applying remote JSON changes to the DOM]

It seems to me there are two approaches to this:

1) Add an explicit suspect/resume API to MutationObserver which does what you
might guess.
2) Add some sort of pullMutations() call which would allow code to
synchronously fetch any queued records, thus making it safe to use
disconnect/observe.

Editorial:

1) Has the benefit of being a fairly clear API given the use and might also
allow the user agent to better optimize usage because what's needed is actually
being expressed. However (as Adamk noted), it has the down side that suspend()
may be confused with disconnect() and cause the DOM to be doing alot of
unneeded work
2) Is less direct in its form, but it addresses this use case, and also another
use which we've suspected we'd eventually need: the desire to "pull" mutations
because you'd like to synchronize your state one an imperative API call.

My $.02: I prefer adding something like pullMutations() because I think we'll
need it for other reasons, and it kills two birds with one stone. Also, as much
as I like the directness of suspend/resume, I'm worried about pages calling
suspend and never calling resume.

Opinions?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 3 April 2012 00:22:30 UTC