Skip to content

Loading…

IE problems #32

Closed
domenic opened this Issue · 15 comments

2 participants

@domenic
Chai.js Assertion Library member

IE10 refuses to run while the document is in quirks mode. So first, that needs to be fixed, by adding <!DOCTYPE html> to index.html.

After that, here are the problems I am discovering on IE10 developer preview (10.0.8102.0). There are lots of them, somewhat surprisingly given its excellence at test-262.

The name property

Chai uses the name property in its assertion messages, which functions do not have in IE. Thus you get lots of failures like

AssertionError: expected 'expected 3 to be an instance of Foo' to equal 'expected 3 to be an instance of undefined'

Other problems with inspect and the messages it produces

Various other tricks that inspect is doing fail:

AssertionError: expected 'expected \'asd\' to have a property \'constructor\' of [Function: Number], but got [Function: String]' to equal 'expected \'asd\' to have a property \'constructor\' of [Function], but got [Function]'

typeof this === "object" for numbers.

This one's wierd.

When using should, numbers get inspected as "{}". E.g. typing this in the console:

(0).should.not.be.ok

gives the assertion error expected {} to be falsy. This in turn is because (0).should.inspect === "{}", which is because `typeof (0).should.obj === "object".

Here's the problem: inside the getter for Object.prototype.should, typeof this === "object" and also this instanceof Number === false. This seems like an IE bug or perhaps a place the spec isn't clear enough in. Fascinating... and evil.

Reproduced at this JSFiddle: Firefox says nothing (?), Chrome says number, IE says object.

@logicalparadox
Chai.js Assertion Library member

Sounds like evilness all around. Why can't we all just get along?

Was hoping it would be less dramatic. For now, I will add the doctype to the tests just so we can keep track of their progress. I don't want to go out of the way to support these issues as it might change and I want to keep chai as clean as possible. Can revisit upon official release... would like to see at least one version of IE like should :P

Thought: Are any of these are similar to the problem preventing IE9 from using should?

Thanks @domenic for the report, and consistently volunteering to be the goto person for IE/chai questions.

@domenic
Chai.js Assertion Library member

I can test IE9 at work tomorrow. I'm actually running Windows 8 as my primary OS at home, so no clue there :P.

Agreed that waiting for official release is the way to go.

@domenic
Chai.js Assertion Library member

IE9 also "fails" the typeof fiddle.

@domenic
Chai.js Assertion Library member

For reference this seems to have to do with http://es5.github.com/#x10.4.3. Basically function calls on primitives use the ToObject coercion in non-strict mode, but use the value directly in strict mode.

IE9 fails the relevant tests for strict mode in test262.

Curiously according to the spec I think Chrome et al. should be giving object as well, instead of number, since Chai is non-strict. I will see if adding "use strict" and re-running in IE10 fixes things, which would be very interesting.

@logicalparadox
Chai.js Assertion Library member

it should be noted that we recently abandoned typeof for actual type checks in favor of a more browser friendly toString approach. You can see it here: https://github.com/logicalparadox/chai/blob/master/lib/assertion.js#L539-548

Perhaps something similar in the loading of should style?

@domenic
Chai.js Assertion Library member

This is actually a much more insidious issue than it appears. Of Firefox, IE9, Chrome, and Safari, only Firefox and IE9 agree on my revised and expanded typeof test. I've posted to es-discuss about this asking for help determining what's correct.

But yes, I think because this seems to be such a buggy (or underspecified?) area, typeof cannot be used, even internally, in conjunction with should.

Depending on how much free time I have after work I'll see if converting all typeofs to toString-based detection fixes a bunch of issues.

@domenic
Chai.js Assertion Library member

This is effin' hopeless. IE10 Consumer Preview:

>> Object.defineProperty(Object.prototype, "x", { get: function () { return this; } })
>> (5).x
0

@logicalparadox
Chai.js Assertion Library member
@domenic
Chai.js Assertion Library member

Nope, things are well and truly messed up.

>> Object.defineProperty(Object.prototype, "x", { get: function () { return this instanceof Number; } });
>> (5).x
false

@domenic
Chai.js Assertion Library member

The only way to reliably detect the presence of numbers is Object.prototype.toString.call(this), but even if you do that, IE thinks that this is always zero.

@domenic
Chai.js Assertion Library member

Was able to fix many of these problems; most notably, I used a Function.prototype.toString hack to detect a function's name in IE. Along with various other tweaks, this makes all of the expect tests pass. Due to the above-discussed issues with getters on Object.prototype, though, should is more or less unfixable for now.

@domenic
Chai.js Assertion Library member

I filed a bug with IE, as well as a bug with test-262 regarding how this isn't covered under existing specs. Gives us something to point to when explaining why should is borked in IE, at least.

@domenic
Chai.js Assertion Library member

I am happy to report that the version of IE10 that comes with Windows 8 Release Preview has none of these bugs! All of the should tests pass, finally!

@logicalparadox
Chai.js Assertion Library member

Fantastic news!

@domenic
Chai.js Assertion Library member

Closing in favor of more specific issues.

@domenic domenic closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.