Bug 78639 - [MutationObservers] Clear pending mutation records on disconnect()
Summary: [MutationObservers] Clear pending mutation records on disconnect()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adam Klein
URL:
Keywords:
Depends on:
Blocks: 68729
  Show dependency treegraph
 
Reported: 2012-02-14 15:03 PST by Rafael Weinstein
Modified: 2012-02-27 18:34 PST (History)
6 users (show)

See Also:


Attachments
Patch (4.89 KB, patch)
2012-02-27 14:37 PST, Adam Klein
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Weinstein 2012-02-14 15:03:55 PST
It's pretty strange to call disconnect() and still *possibly* get one invocation of your callback. We should just clear any pending deliveries.

It's possible that script way want to know immediately prior to calling disconnect() *what* mutation records are pending delivery. If this happens in practice, we can add a method to synchronously retrieve & clear pending mutation records.
Comment 1 Ryosuke Niwa 2012-02-14 15:28:25 PST
What does the spec says?
Comment 2 Adam Klein 2012-02-14 15:30:40 PST
(In reply to comment #1)
> What does the spec says?

The spec matches the current behavior. Once the text is part of DOM4 (annevk said he was going to patch it in this week), we'll open a bug there too.

This bug should be seen as depending on the spec change.
Comment 3 Ryosuke Niwa 2012-02-14 15:41:30 PST
(In reply to comment #2)
> The spec matches the current behavior. Once the text is part of DOM4 (annevk said he was going to patch it in this week), we'll open a bug there too.
> 
> This bug should be seen as depending on the spec change.

Okay. Could you guys start a new thread or reply to an existing thread about this? I would be interested to hear what Jonas and Olli have to say about this.
Comment 4 Adam Klein 2012-02-14 15:43:36 PST
(In reply to comment #3)
> (In reply to comment #2)
> > The spec matches the current behavior. Once the text is part of DOM4 (annevk said he was going to patch it in this week), we'll open a bug there too.
> > 
> > This bug should be seen as depending on the spec change.
> 
> Okay. Could you guys start a new thread or reply to an existing thread about this? I would be interested to hear what Jonas and Olli have to say about this.

As noted above, my plan is to file this as a bug against the spec once the initial spec text is checked in. I asked Raf to file this bug since we were just talking about it and I didn't want it to get lost.
Comment 5 Ryosuke Niwa 2012-02-14 15:44:14 PST
(In reply to comment #4)
> As noted above, my plan is to file this as a bug against the spec once the initial spec text is checked in. I asked Raf to file this bug since we were just talking about it and I didn't want it to get lost.

Okay. That makes sense.
Comment 6 Adam Klein 2012-02-23 10:25:20 PST
(In reply to comment #5)
> (In reply to comment #4)
> > As noted above, my plan is to file this as a bug against the spec once the initial spec text is checked in. I asked Raf to file this bug since we were just talking about it and I didn't want it to get lost.
> 
> Okay. That makes sense.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16092
Comment 7 Adam Klein 2012-02-27 14:37:49 PST
Created attachment 129100 [details]
Patch
Comment 8 WebKit Review Bot 2012-02-27 18:34:37 PST
Comment on attachment 129100 [details]
Patch

Clearing flags on attachment: 129100

Committed r109058: <http://trac.webkit.org/changeset/109058>
Comment 9 WebKit Review Bot 2012-02-27 18:34:42 PST
All reviewed patches have been landed.  Closing bug.