trying to understand visitNode inside processMutations

[Jelte Liebrand]

Hey guys,

I've been trying to debug a problem I found where the summary object contains more information than the original mutation record.  I raised a bug on the project pages here:

http://code.google.com/p/mutation-summary/issues/detail?id=10

Having been stepping through the code, I can't quite understand why visitNode actually recurses into the nodes children?  In my case, the first mutation record has the P node as an added node, but it's children (SPAN and BR) are not in the mutation record itself. So shouldn't visitNode not simply visit the P and not worry about the children?

If i comment out the for loop that visits the children, then my summary objects appear to be correct compared to the mutation records.  But I clearly don't want to just comment out the code without knowing what it was intended for ;-)

/Cheers,

Jelte

[Jelte Liebrand]

Hey,

OK so ignore my mail from yesterday.  The mutation records report a childList, so indeed the summary library *should* be iterating over the children and reporting all nodes as "added".

However, the fact I get three callbacks from the mutation observer is the odd and possibly broken bit.  According to the mutation records, things get added twice, when clearly it isn't added twice.

I'll continue debugging, but I am no longer (overly ;-)) confused by the projection's processMutations... My confusion has shifted towards the mutation observer itself :-)

/Cheers,

Jelte

--
You received this message because you are subscribed to the Google Groups "mutation-summary-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mutation-summary-discuss/-/Y53EnO7b2jIJ.
To post to this group, send email to mutation-sum...@googlegroups.com.
To unsubscribe from this group, send email to mutation-summary-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mutation-summary-discuss?hl=en.

--

Jelte Liebrand | Software Engineering Manager | je...@google.com | +44 7970 288 310

[Jelte Liebrand]

OK... I am clearly an idiot... I finally tracked down my bug... and indeed it is MY bug :-(

Turns out a completely different part of our system was still using the old DOMSubTreeModified event, and indeed fiddling with the DOM when that event fired.  This in turn meant that the mutation observer had to fire in the middle of mutations.

One more notch on the (by now long) list of why the old mutation events suck!  

Removing that bit of offending code means the mutation records come through *correctly* and the subsequent summary objects are all good too.

I'll add some comments on the bug i raised to please feel free to delete that issue (and another issue i raised). I'd delete them myself, but I dont think i can (nor edit them?).  

I think we still need the "previous old sibling" on deleted nodes though, but that's a separate topic.

My apologies for wasting space in all your inboxes with this thread :-S

/Cheers,

Jelte

[Rafael Weinstein]

Glad you found the issue.

It's still on my list to look at adding a config option for previousOldSibling.

Thanks for leading the path on usage!

R

[Jelte Liebrand]

No probs!  Lemme know if you want me to trial run something for previousOldSibling;  for now it's not quite blocking us, so that's good news.

I'll continue to bash on our editor to see if there are other edge cases I've not yet thought about.

/Cheers,

Jelte