Ignore mutation events from within atoms

[rlivsey]

ember-mobiledoc-editor uses ember-wormhole to insert components into
atom placeholders. This immediately causes a mutation and then
the editor update is triggered when nothing has changed.

Atoms are their own world and so any changes in them should be safe
to ignore.

[rlivsey]

If this is good, we might need to do the same for cards as they are inserted in the same way using wormholes in ember-mobiledoc-editor?

[rlivsey]

Failure is saucelabs

[bantic]

Thanks for this, makes total sense to me. I am wondering if it would be easier to delegate the responsibility to the render node the way we do for sections with renderNode.reparsesMutationOfChildNode.
I'll take a look at those sauce failures. I restarted the CI build for this yesterday but it seems to have failed in the same way again.

[rlivsey]

Makes sense for this to be a renderNode concern, I'll take a look at that

[bantic]

This needs to be el = el.parentNode in order for IE to pass. IE doesn't define parentElement on Node, only on Element (and a textNode is a Node but not an Element). (Thanks a lot, IE.)

[bantic]

@rlivsey I added a few comments. This looks good to me. I will do a mini spike to try finding a render node (instead of a section render node) for the mutations to check the feasibility of simply delegating the shouldReparse logic to the render node itself, that feels a bit cleaner and also potentially more future-safe.

[rlivsey]

@bantic thanks, I'll make those tweaks later tonight

[bantic]

@rlivsey When you have a chance could you test this branch out? Moving reparsing logic onto the render nodes seems to work reasonably well:
master...ignore-atom-mutations-via-render-nodes

[bantic]

@rlivsey Ping. Did you have a chance to check out the spike on the branch I mentioned before? If that works I'd be happy to fold it in and finish up work here. Would love to get this merged.

[bantic]

@rlivsey Thanks for this PR! I rebased and added a few additions (delegating reparsing to render nodes, mostly) in #362. thanks!