assertIsNodeWrapper triggering Firefox and IE11

[wasbridge]

When using jQuery (specifically the DataTables.net plugin) in combination with polymer in Firefox (latest) or IE11 assertIsNodeWrapper is triggered on the following jQuery (line 5641, version 2.1.4) function call

var pixelPositionVal, boxSizingReliableVal,
        docElem = document.documentElement,
        container = document.createElement( "div" ),
        div = document.createElement( "div" );

...

function computePixelPositionAndBoxSizingReliable() {
    div.style.cssText =
        // Support: Firefox<29, Android 2.3
        // Vendor-prefix box-sizing
        "-webkit-box-sizing:border-box;-moz-box-sizing:border-box;" +
        "box-sizing:border-box;display:block;margin-top:1%;top:1%;" +
        "border:1px;padding:1px;width:4px;position:absolute";
    div.innerHTML = "";
    docElem.appendChild( container );

    var divStyle = window.getComputedStyle( div, null );
    pixelPositionVal = divStyle.top !== "1%";
    boxSizingReliableVal = divStyle.width === "4px";

    docElem.removeChild( container );
}

The assert is thrown for both the appendChild and removeChild.

The reason the assert is called is because 'container' is not wrapped by webcomponents.js

I was manually able to correct this error by making sure to call wrapIfNeeded before any assertIsNodeWrapper call in webcomponents.js

[wasbridge]

BUMP. Any insight? Would people like more info?

[jmesserly]

this kind of thing comes up decently often, I seem to recall @garlicnation or @addyosmani did a good writeup in another issue. But basically there are a few common culprits.

1. Shadow DOM polyfill must be loaded first, before other scripts
2. Some libraries are not Shadow DOM aware and may not expect parts of the DOM tree to be hidden, e.g. they expect to be able to querySelector/getElementById to find any node in the whole document, or maybe they expect .parentNode to always find the root document, or MutationObservers to see all changes, etc.
3. Styles can be messed up for similar reasons as 2, but that wouldn't cause an exception in the code, typically, so probably not the culprit in your case.
4. document and other accessors cannot be patched, so things like document.body.firstChild will give an unwrapped node. Libraries may use this without knowing. In contrast, document.querySelector('body').firstChild would work.

My guess is 4, based on the symptom. Here's some more explanation:

ShadowDOM polyfill works by wrapping all nodes in the DOM, to present a ShadowDOM aware view. All DOM traveral APIs are affected (e.g. firstChild, parentNode, querySelector). Unfortunately we cannot patch document or its accessors, so chains of accessors will yield unwrapped nodes. There is no way to fix that in the polyfill code until Chrome and Safari make accessors patchable (they are both working on fix, but unclear when we can rely on it). That's the bad news.

The good news: you can usually workaround this by wrapping the library in question, like this

<script>
(function(document) {
 // ... library goes here ...
})(ShadowDOMPolyfill.wrap(document));
</script>

[wasbridge]

Thank you so much for your very thorough explanation -- I think I can work
around this bug using the technique you described.

I really appreciate it!!!

On Fri, May 15, 2015 at 12:27 PM, John Messerly notifications@github.com
wrote:

this kind of thing comes up decently often, I seem to recall @garlicnation
https://github.com/garlicnation or @addyosmani
https://github.com/addyosmani did a good writeup in another issue. But
basically there are a few common culprits.

Shadow DOM polyfill must be loaded first, before other scripts
2.

Some libraries are not Shadow DOM aware and may not expect parts of
the DOM tree to be hidden, e.g. they expect to be able to
querySelector/getElementById to find any node in the whole document, or
maybe they expect .parentNode to always find the root document, or
MutationObservers to see all changes, etc.
3.

Styles can be messed up for similar reasons as 2, but that wouldn't
cause an exception in the code, typically, so probably not the culprit in
your case.
4.

document and other accessors cannot be patched, so things like
document.body.firstChild will give an unwrapped node. Libraries may
use this without knowing. In contrast,
document.querySelector('body').firstChild would work.

My guess is 4, based on the symptom. Here's some more explanation:

ShadowDOM polyfill works by wrapping all nodes in the DOM, to present a
ShadowDOM aware view. All DOM traveral APIs are affected (e.g. firstChild,
parentNode, querySelector). Unfortunately we cannot patch document or its
accessors, so chains of accessors will yield unwrapped nodes. There is no
way to fix that in the polyfill code until Chrome and Safari make accessors
patchable (they are both working on fix, but unclear when we can rely on
it). That's the bad news.

The good news: you can usually workaround this by wrapping the library in
question, like this

<script>(function(document) { // ... library goes here ...})(ShadowDOMPolyfill.wrap(document));</script>

—
Reply to this email directly or view it on GitHub
#301 (comment)
.