Error !supportsAccessors was thrown on XP IE 8

[Jeff-Tian]

[ljharb]

Can you provide any more information?

[ljharb]

This seems like something from es5-sham, which isn't guaranteed to work on older browsers. I'm going to close this until there's further information.

[message]

Same issue. Using IE8 on Win7 + React.

[ljharb]

@message Thanks for confirming - it's indeed in es5-sham.js, which will sometimes fail in older browsers.

[wadeharrell]

MSDN: Exception thrown and not caught

You included a throw statement in your code, but it was not enclosed within a try block, or there was no associated catch block to trap the error. Exceptions are thrown from within the try block using the throw statement, and caught outside the try block with a catch statement. To correct this error:

1. Enclose code that can throw an exception in a try block, and ensure there is a corresponding catch block.
2. Make sure your catch statement expects the correct form of exception.
3. If the exception is rethrown, make sure there is another corresponding catch statement.

I am getting this all over es5-sham in IE10 running developer tools under "Browser Mode: IE8", almost all instances of "throw new TypeError" are not enclosed in a try{}catch{} and IE is not cool with that. Will see if I can massage it a bit into working and submit a pull request if I solve it. Attempting to build a React.js site but have IE requirements. Odd, es5-shim does the same thing, but I guess they are hidden from IE.

[ljharb]

That's intentional. Wrapping it in a try/catch would mask the fact that the behavior is failing. Your own user code should have a try/catch when using the sham, since es5-sham can't possibly guess what you want to do in the case of the behavior not being possible (everything in es5-shim can be shimmed, everything in the sham can only be partially shimmed).

If you want to build a React site, you can't expect it to work on a browser that React itself doesn't support :-/

[wadeharrell]

might want to ask FB to remove the bit of their docs that explicitly says you can get IE8 support with es5-sham https://facebook.github.io/react/docs/working-with-the-browser.html#polyfills-needed-to-support-older-browsers

[wadeharrell]

how about if sham uses the defineProperties function from shim? so defineProperties(ObjectPrototype, { defineProperty: function ... });

[ljharb]

If there's a way we can figure out what's happening and make React work with IE 8 (which as you pointed out, is supposed to work) then I'd love to do that.

@wadeharrell Can you try older versions of the es5-shim's sham file, and see if you can help me pinpoint if a specific version created the breakage?

[diffractometer]

Hello,

Looking for any help here.

I'm getting the same error in IE8. I'm using react-router (1.0 beta 3) and es5-sham (4.1.0) for polyfills. I understand 1.0 doesn't use getters but it does not seem to have resolved the problem for me.

Issue 249 on es5-shim is closed and yet I am unable to determine from the thread if they gave up on ie8 support in sham or not.

Thanks.

[diffractometer]

Thanks again,

The error showed up when I added React Router, which claims to no longer be using getters and setters. According to @ryanflorence in 1095: 'master (1.0 API) is IE8 compatible (removed all the babel and getter stuff)' Also in 1022 'we don't have anymore getters'.

When I remove es5-sham I get the error

Object doesn't support property or method 'freeze':

on line 16 of Object.js

if ("production" !== "development") {
  Object.freeze(emptyObject);
}

IE8 emulator is also saying something is going wrong in ReactDOMComponent.js but it's not highlighting the line, argh, but looks like * something * in here:

/**
   * Creates markup for the content between the tags.
   *
   * @private
   * @param {ReactReconcileTransaction|ReactServerRenderingTransaction} transaction
   * @param {object} context
   * @return {string} Content markup.
   */
  _createContentMarkup: function(transaction, context) {
    var prefix = '';
    if (this._tag === 'listing' ||
        this._tag === 'pre' ||
        this._tag === 'textarea') {
      // Add an initial newline because browsers ignore the first newline in
      // a <listing>, <pre>, or <textarea> as an "authoring convenience" -- see
      // https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inbody.
      prefix = '\n';
    }

    var props = this._currentElement.props;

Any insight would be immensly appreciated. Am I wrong to think that React router is still the cause of the error? Espcially in light of their declaired disuse of getters? Maybe it's actually React?

[diffractometer]

@ljharb thanks for offering to debug, I ended up resolving the issue. I can verify that React Router 3 is playing nice with es5-sham.

The issue was I had my project mounted on an API as a submodule and the build using Browserify was conflicting with another submodule which was still using Reactify. I didn't realize it but the other submodule was somehow pulling in the old version of React Router or something to that effect. Anyway all good.

Cheers.

[ljharb]

Gotcha, thanks for confirming!