NotSupportedError: DOM Exception 9: The implementation did not support the requested type of object or operation.

[tobyzerner]

As of 270b20a, I'm getting this error in Safari (9.0.1). Chrome is unaffected.

NotSupportedError: DOM Exception 9: The implementation did not support the requested type of object or operation.

The stack trace points to createContextualFragment on this line. Looking back at the previous commit, it looks like this part was refactored and a surrounding try/catch was removed?

[dead-claudia]

PRs + tests welcome!

[nianwang]

Example on Safari 9.0.2 (11601.3.9), for tag v0.2.2-rc1 (works as of v0.2.1):

var example = {
  view: function() {
    return m('div', [
      m('p', '©'),
      m('p', m.trust('©')),
      m.trust('©')
    ]);
  }
}

m.mount(document.body, example);

[dead-claudia]

Is there a more minimal example?

On Mon, Jan 4, 2016, 15:53 Nian Wang notifications@github.com wrote:

Example on Safari 9.0.2 (11601.3.9), for tag v0.2.2-rc1

var example = {
view: function() {
return m('div', [
m('p', '©'),
m('p', m.trust('©')),
m.trust('©')
]);
}
}

m.mount(document.body, example);

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

[iamjohnlong]

Seems to be

document.createRange().createContextualFragment('<div>I am a div node</div>')

Isn't supported in safari even though it has the native method.

Would reverting back to a try/catch be acceptable @isiahmeadows ?

[dead-claudia]

Yes, but pull the try/catch out into its own function to keep Chrome from refusing to optimize the whole function. What would be best would be to pull it out into its own independent function:

function appendTextFragment(parentElement, data) {
  try {
    parentElement.appendChild($document.createRange().createContextualFragment(data))
  } catch (e) {
    parentElement.insertAdjacentHTML("beforeend", data)
  }
}

// And in injectHTML
if (nextSibling) {
  // ...
} else {
  appendTextFragment(parentElement, data)
}

[barneycarroll]

I was looking over Cito source earlier and noticed a lot of similar environment-dependent forking in frequently used functions. My ignorance of under-the-hood JIT optimisation logic leaves me somewhat unqualified, but wouldn't the best approach be to run a memoized function to test for this edge case on first execution and thereafter return the stored outcome?

Back in the day when I wrote engine-dependent implementation forks of repeatedly-invoked functions, the function reference itself would be the test, that upon execution re-assigned the reference to point to the engine-specific variation. I get the impression this completely short-circuits certain engines procedures for optimising run time, but never found a way to validate the assertion.

[iamjohnlong]

I'm not sure how to write a test for this @isiahmeadows

#923

[dead-claudia]

@barneycarroll That won't work with m.deps(), since the mock will be used from the start. Otherwise, I would've already suggested that.

[dead-claudia]

Maybe once we get rid of the stupid mock, maybe it might work.

[barneycarroll]

Argh. Yeah, I see that problem ;)

[dead-claudia]

The only thing that even needs mocked is the XMLHttpRequest, so we aren't actually requesting anything, and can still read headers.

[pygy]

Don't forget requestAnimationFrame for coercing async into sync behavior (unless you want to rewrite all the async tests on top of m.hook, if it ever lands...

[dead-claudia]

@pygy That, too. I didn't think of that. But the rest is probably best suited to die in the fires of /dev/null. 😄

[gabrieleceranto]

Hi all, i just encountered first time this bug. After some try, i found solution to let him work in safari (and other browsers too):

var range = $document.createRange();
range.selectNode(parentElement);
parentElement.appendChild(range.createContextualFragment(data));

I originally found bug in safari 5.1.10, so i guess this bug affect all recent safari versions

[dead-claudia]

@gabrieleceranto It's fixed: #923

[cmnstmntmn]

i still get it in Safari v. 9.0.2 (11601.3.9) with Mithril v0.2.2-rc.1

[tivac]

@cmnstmntmn Not surprising, v0.2.2-rc1 was cut before the fix in #923 landed.

[dead-claudia]

I think @lhorie will probably cut out another -rc at some point. There's a few other things remaining (like passing more of the new test suite).