Crashing IE 6

[RobG]

Over at Ajaxian they are all agog that someone was clever enough to
write a jQuery plugin to crash IE 6.

<URL: http://ajaxian.com/archives/jquery-one-line-plugin-to-crash-ie6#comments
The code in question is:

;jQuery.crash=function(x){for(x in document.open);};

Of course jQuery itself is irrelevant, but it is humorous to see the
guesses at why IE crashes on that particular line of code. There are
any number of other host methods that can be substituted for
document.open that will crash IE (window.alert,
document.getElementById, and so on).

It seems to me that this should be a well known bug, but I can't find
a reference to it in the clj archives.

Can anyone offer a succinct explanation?

 

[Asen Bozhilov]

The code in question is:

;jQuery.crash=function(x){for(x in document.open);};

It seems to me that this should be a well known bug, but I can't find
a reference to it in the clj archives.

The process of enumeration is implementation depended. ECMA-262
doesn't describe the algorithm for:

| Get the name of the next property of Result(3) that doesn't
| have the DontEnum attribute. If there is no such
| property, go to step 14.

That behavior described by specification is regard native objects.
Applying reference to host object as `Expression` in `for-in`
statement behavior can differ from described by specification.

Can anyone offer a succinct explanation?

Operation System can and should terminate immediately any processes,
which do unsafe operations. In presented case, during evaluation of
`for-in` statement the environment try to do unsafe operation and OS
terminate that process. It's a bug in IE, because IE should observing
unsafe operation in the user scripts. If there is unsafe operation, IE
should inform the user for that and terminate the execution of the
program.

 

[David Mark]

Over at Ajaxian they are all agog that someone was clever enough to
write a jQuery plugin to crash IE 6.

<URL: http://ajaxian.com/archives/jquery-one-line-plugin-to-crash-ie6#comments

Did you misspell aghast?

Another scoop. Odd those bums would publish something like that, but
nothing yet (after 2.5 years) about My Library. Though, as a user noted
recently, it may have something to do with the fact that I haven't
submitted an article. And I'm never going to as reporters (not the
makers) are supposed to write articles about news. The other way around
and you have the journalistic equivalent of an informercial.

The code in question is:

;jQuery.crash=function(x){for(x in document.open);};

That's about as useful as any other line of jQuery code.

Of course jQuery itself is irrelevant, but it is humorous to see the
guesses at why IE crashes on that particular line of code.

Yes and yes. After over four years of trying to sort IE6 out from 2006
and into 2010, one agonizing baby-step patch at a time, their final
"solution" is to petulantly pretend it doesn't exist and now to sabotage
users who attempt to use it. Dojo floated a similar surrender proposal
recently as well. They don't seem to do much better with the
quasi-standards-based browsers either (as of now, Opera 9 and Safari 3
have also vanished in a puff of incompetence in the "minds" of the
library authors). Yes, that's just what browser scripting needed
(interminable losers). And thanks to Crockford for "validating" their
idiocy with mindless propaganda videos. JFTR, there are still plenty of
corporate users (not to mention little old ladies) stuck with IE6.
Don't crash their browsers! Gain some semblance of competence instead
(or find another line of work).

There are
any number of other host methods that can be substituted for
document.open that will crash IE (window.alert,
document.getElementById, and so on).

With a for-in? Whatever.

It seems to me that this should be a well known bug, but I can't find
a reference to it in the clj archives.

Personally, I rarely encounter such bugs as I don't seek to try bizarre
operations on host objects. Avoidance is bliss.

Can anyone offer a succinct explanation?

MS has been known to put out bad software.

 

[Thomas 'PointedEars' Lahn]

The process of enumeration is implementation depended.
Yes.

ECMA-262 doesn't describe the algorithm for:

| Get the name of the next property of Result(3) that doesn't
| have the DontEnum attribute. If there is no such
| property, go to step 14.
True.

That behavior described by specification is regard native objects.

No, it applies to all objects.

Applying reference to host object as `Expression` in `for-in`
statement behavior can differ from described by specification.

But that does not appear to be the problem here.

for (var x in document.open);

executes without error in my IE 6.0.2800.1106. We must therefore conclude
that the JScript of other versions of IE 6 causes the problem or the value
of `x' does. A possibility for the latter is that `x' has been assigned a
reference to a host object and that its [[Put]] implementation would
interfere.


PointedEars

 

[Thomas 'PointedEars' Lahn]

But that does not appear to be the problem here.

for (var x in document.open);

executes without error in my IE 6.0.2800.1106. We must therefore
conclude that the JScript of other versions of IE 6 causes the problem

I should better say "the JScript, or the DOM implementation ...".

or the value of `x' does. A possibility for the latter is that `x' has
been assigned a reference to a host object and that its [[Put]]
implementation would interfere.

PointedEars

 

[Scott Sauyet]

MS has been known to put out bad software.

Like Antarctica has been known to get cold.

-- Scott

 

[Michael Haufe (\TNO\)]

Over at Ajaxian they are all agog that someone was clever enough to
write a jQuery plugin to crash IE 6.

<URL:http://ajaxian.com/archives/jquery-one-line-plugin-to-crash-ie6#comments



The code in question is:

;jQuery.crash=function(x){for(x in document.open);};
...

I don't see why they need a plugin or JS at all. This css seems to do
the trick:

*{position:relative}

 

[Asen Bozhilov]

Asen Bozhilov wrote:

No, it applies to all objects.

The specification isn't describe behavior of host objects.

| ECMAScript program will provide not only
| the objects and other facilities described in this
| specification but also certain environment-specific host objects,
| whose description and behaviour are beyond the scope of this
specification
| except to indicate that they may provide
| certain properties that can be accessed and certain functions
| that can be called from an ECMAScript program.

Therefore `for-in` with reference to a host object as `Expression` can
have different behavior from described by specification.

| 5. Get the name of the next property of Result(3) that
| doesn’t have the DontEnum attribute. If there is no such
| property, go to step 14.

Enumeration of host objects properties can differ from that step. They
can use certainly different algorithm for enumerating that host object
properties.

 

[Thomas 'PointedEars' Lahn]

The specification isn't describe behavior of host objects.

Again, you are mistaken.

| ECMAScript program will provide not only
| the objects and other facilities described in this
| specification but also certain environment-specific host objects,
| whose description and behaviour are beyond the scope of this
specification
| except to indicate that they may provide
| certain properties that can be accessed and certain functions
| that can be called from an ECMAScript program.

Where did you quote this from? It appears to be at least incomplete on the
top.

Therefore `for-in` with reference to a host object as `Expression` can
have different behavior from described by specification.

But _not_ with regard to how enumeration is to be performed in general.
_Only_ with regard to how the certain unspecified behavior is to be
implemented, and with regard to the _internal methods_ employed that are
defined so that host object _do not need_ to implement them as specified in
their algorithms.

Whereas host objects are not at all special in how that certain unspecified
behavior (here: "Get the name of the next property of Result(3)") is
implemented. IOW, the same applies to *all* objects there.

| 5. Get the name of the next property of Result(3) that
| doesn’t have the DontEnum attribute. If there is no such
| property, go to step 14.

Enumeration of host objects properties can differ from that step.

Not at all. The Specification evidentially (sic!) makes no such allowance
there.

They can use certainly different algorithm for enumerating that host
object properties.

No, certainly not. BUT: How "Get the name of the next property ..." is
implemented depends on the object *without* regard to its classification as
native or host object.


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

Where did you quote this from?  It appears to be at least incomplete onthe
top.

That quotation is from: ECMA-262 edition 3, 4 Overview.

Whereas host objects are not at all special in how that certain unspecified
behavior (here: "Get the name of the next property of Result(3)") is
implemented.  IOW, the same applies to *all* objects there.

I agree with you, but:

| 5. Get the name of the next property of Result(3)
| that doesn’t have the DontEnum attribute.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Host object can implement that in way that they want. Enumeration of
the host object properties can certainly different from that described
by specification. What do you think about properties of follow
object:

var xhr = new ActiveXObject('Microsoft.XMLHTTP');

Do you think each property of that host object have {DontEnum}
attribute, because `for-in` doesn't enumerate any properties of that
object?

 

[Thomas 'PointedEars' Lahn]

That quotation is from: ECMA-262 edition 3, 4 Overview.

You have misquoted that, then. The original text is:

| 4 Overview
|
| This section contains a non-normative overview of the ECMAScript
| language.
|
| ECMAScript is an object-oriented programming language for performing
| computations and manipulating computational objects within a host
| environment. ECMAScript as defined here is not intended to be
| computationally self-sufficient; indeed, there are no provisions in this
| specification for input of external data or output of computed results.
| Instead, it is expected that the computational environment of an
| ECMAScript program will provide not only the objects and other facilities
| described in this specification but also certain environment-specific
| host objects, whose description and behaviour are beyond the scope of
| this specification except to indicate that they may provide certain
| properties that can be accessed and certain functions that can be called
| from an ECMAScript program.

The key words/parts here being "non-normative overview" and "expected that
the computational environment of an ...", which you overlooked/omitted, but
which change both the level of requirement and the meaning of the text.

I agree with you, but:

| 5. Get the name of the next property of Result(3)
| that doesn’t have the DontEnum attribute.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Host object can implement that in way that they want.

No. Either the property has that attribute or it has not. The marked part
is not different with native objects, and certainly provides no excuse for
a "crash" of any kind with a host object.

Enumeration of the host object properties can certainly different from
that described by specification.

No, certainly not.

What do you think about properties of follow object:

var xhr = new ActiveXObject('Microsoft.XMLHTTP');

Do you think each property of that host object have {DontEnum}
attribute, because `for-in` doesn't enumerate any properties of that
object?

Whether the property has the attribute or not is beside the point, and it
certainly has nothing to do with an object being a host object or not.

What is allowed to be arbitrary here is only the way the name of the next
property is determined. If there is such a property, then it must not have
the DontEnum attribute set to be considered; if there is no such property,
the algorithm must end (and must not cause a "crash" of any kind).


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

The key words/parts here being "non-normative overview" and "expected that
the computational environment of an ...", which you overlooked/omitted, but
which change both the level of requirement and the meaning of the text.

Non-normative sections in normative documents, provide additional
information about normative sections of document. If normative section
of document interfere with non-normative, normative sections has
precedence than non-normative information.
The description of `for-in` statement is part of normative section of
ECMA-262 standard. That description doesn't have information, which
interfere with non-normative information of ECMA-262 standard. While
there isn't explicit information about `for-in` behavior with host
objects, that behavior is out of scope of specification.

No.  Either the property has that attribute or it has not.  The marked part
is not different with native objects,

Enumeration of properties of host objects depend by iterator of host
object. ECMA-262 describe semantic only of native objects. Except case
where explicit say regard host objects. {DontEnum} attribute is
defined by `8.6 The Object Type` in table, which is part of `8.6.1
Property Attributes`. The whole section 8.6 describe semantic of
native objects. Regarding that section, `for-in` behavior is related
with native objects not with host objects.

and certainly provides no excuse for
a "crash" of any kind with a host object.

Certainly true. Crash like that is a bug in environment. Environment
should avoid unsafe operations, because OS can terminate that process
immediately.

Regards and happy Easter.

 

[Thomas 'PointedEars' Lahn]

Asen Bozhilov wrote:
The key words/parts here being "non-normative overview" and "expected
that the computational environment of an ...", which you
overlooked/omitted, but which change both the level of requirement and
the meaning of the text.

Non-normative sections in normative documents, provide additional
information about normative sections of document.
Nonsense.

[...]
The description of `for-in` statement is part of normative section of
ECMA-262 standard. That description doesn't have information, which
interfere with non-normative information of ECMA-262 standard. While
there isn't explicit information about `for-in` behavior with host
objects, that behavior is out of scope of specification.

Non sequitur. There is no explicit information about `for-in' behavior
with native objects either.

Enumeration of properties of host objects depend by iterator of host
object.

No argument about that.

ECMA-262 describe semantic only of native objects.

It does not describe how "the next property ..." of native objects is to be
retrieved either. In fact, it says:

| 8.6 The Object Type
|
| An Object is an unordered collection of properties. [...]

Again, this has nothing to do with whether an object is a host object or a
native object.

Except case where explicit say regard host objects.

You have it backwards. Except in cases where the Specification explicitly
refers to native objects, or host objects, it applies to *all* objects.

{DontEnum} attribute is defined by `8.6 The Object Type` in table, which
is part of `8.6.1 Property Attributes`. The whole section 8.6 describe
semantic of native objects.

No, it describes the semantics of values of the Object type, which are all
values that are not of one of the other types. That would *include* host
objects, of course. (It should be obvious that otherwise the for-in
algorithm did not make any sense, as there is no provision for host objects
whatsoever in it, and a language feature must be universally applicable
unless explicitly stated otherwise.)

Regarding that section, `for-in` behavior is related with native objects
not with host objects.

You are wrong. Host objects can be either of the Object type or (per the
Conformance section) of a object type not specified in ECMAScript. In any
case, in a *conforming* implementation the object still must implement the
[[DontEnum]] property attribute as specified.

In particular, a host object that is callable, like that referred to by
`document.open', MUST be of the Object type in a *conforming*
implementation; otherwise a TypeError exception would need be thrown when
calling it, per ES3F/ES5, section 11.2.3, step 4, as Type(...) would not be
`Object'.

Certainly true. Crash like that is a bug in environment.

Yes, the implementation might not be conforming. Unfortunately, it is
impossible to tell without knowing what the argument `x' of the crash()
method stored when the method was called.

Environment should avoid unsafe operations, because OS can terminate that
process immediately.
Gibberish.

Regards and happy Easter.

Thanks, you too.


PointedEars

 

[Asen Bozhilov]

Asen Bozhilov wrote:

Nonsense.

Conclusion like that, doesn't approve your words at all.

Gibberish.

Same as first...

There are lots of example with `for-in`, which deviate from behavior
which described by specification.

var javaString = new java.lang.String("");

window.alert(javaString.hasOwnProperty('getBytes')); //true
window.alert(javaString.propertyIsEnumerable('getBytes')); //true

window.alert(javaString.hasOwnProperty('startsWith')); //true
window.alert(javaString.propertyIsEnumerable('startsWith')); //true

var props = '';
for (var i in javaString) {
props += i + '\n';
}
window.alert(props);

And:

window.alert(Object.prototype.hasOwnProperty.call(java, 'lang')); //
true
window.alert(Object.prototype.propertyIsEnumerable.call(java,
'lang')); //true

try {
for (var i in java);
}catch(e) {
window.alert(e);
}

Host objects are out of scope of ECMA-262 specification. Only section
`8.6.2 Internal Properties and Methods` describe, "Every object
(including host objects) must implement all Internal Properties and
Methods", which are in the table in that section. When specification
use the word "object" that mean native object and described behavior
is regard native objects. And of course behavior with host objects is
implementation depended.

 

[John G Harris]

No, it describes the semantics of values of the Object type, which are all
values that are not of one of the other types. That would *include* host
objects, of course. (It should be obvious that otherwise the for-in
algorithm did not make any sense, as there is no provision for host objects
whatsoever in it, and a language feature must be universally applicable
unless explicitly stated otherwise.)

<snip>

A few days ago you were saying that host objects were part of an API and
definitely not part of a programming language. Now you're saying their
behaviour is specified by ECMA 262.

You aren't very consistent, are you ?

John

 

[Dr J R Stockton]

In comp.lang.javascript message <bbcb2641-e0f2-442a-a879-6efa1abb791b@r2
7g2000yqn.googlegroups.com>, Fri, 2 Apr 2010 03:46:59, RobG

Over at Ajaxian they are all agog that someone was clever enough to
write a jQuery plugin to crash IE 6.

Do you mean that it actually CRASHES IE 6, meaning that it does
something disorderly and the operating system terminates it or also
crashes ; or do you mean that IE 6 exits in an orderly manner casting
aspersions while internally remaining under perfect control?

What are the exact symptoms?

 

[Thomas 'PointedEars' Lahn]

Conclusion like that, doesn't approve your words at all.

It is not a conclusion, it is a fact.

As to my real conclusions, you have ignored them and not even quoted them.
I am getting the idea you want to forge my statements here.

Same as first...

Again, it is not opinion but a fact that this is not a coherent statement.

There are lots of example with `for-in`, which deviate from behavior
which described by specification.

You do not appear to understand that the Specification does not contain a
_full_ description of what for-in should do, for *all* objects.
Specification is clearly limited by the fact that the algorithm description
does not include how "the next property" should be retrieved. Everything
else, however, is specified, and a conforming implementation must comply
with it, with *all* objects, built-in and host objects with an ECMAScript
binding to that implementation.

var javaString = new java.lang.String("");

window.alert(javaString.hasOwnProperty('getBytes')); //true
window.alert(javaString.propertyIsEnumerable('getBytes')); //true

window.alert(javaString.hasOwnProperty('startsWith')); //true
window.alert(javaString.propertyIsEnumerable('startsWith')); //true

var props = '';
for (var i in javaString) {
props += i + '\n';
}
window.alert(props);

This is just code. If you want to make a point, you should say what
outcome you did observe when running it, and you should definitely state in
which runtime environment you did observe it.

However, I suppose you wanted to point out that none of those properties
Nevertheless, hasOwnProperty() has of course nothing to do with the
[[DontEnum]] attribute, so your logic is flawed.

And:

window.alert(Object.prototype.hasOwnProperty.call(java, 'lang')); //
true
window.alert(Object.prototype.propertyIsEnumerable.call(java,
'lang')); //true

try {
for (var i in java);
}catch(e) {
window.alert(e);
}

Again, your example is pointless.

Host objects are out of scope of ECMA-262 specification.

No. Their existence and behavior is very clearly specified there up to the
point where they must no longer follow the specified algorithms. for-in
includes no such provision.

Only section
`8.6.2 Internal Properties and Methods` describe, "Every object
(including host objects) must implement all Internal Properties and
Methods",

No. This definition is inclusive, not exclusive, with regard to host
objects.

which are in the table in that section. When specification
use the word "object" that mean native object

No. You are imagining things.


PointedEars

 

[Thomas 'PointedEars' Lahn]

A few days ago you were saying that host objects were part of an API and
definitely not part of a programming language.

You are misconstruing my statements, constructing a contradiction where
none exists. Host objects *are* implementations of (or, if you will, part
of) an API. That API is language-independent most of the time, but would
provide ECMAScript binding to work in the runtime environment of an
ECMAScript implementation. So host objects still *are* *not* part of the
ECMAScript implementation.

Now you're saying their behaviour is specified by ECMA 262.

Their behavior is evidentially (sic!) specified by ECMA-262 up to a certain
point. The scope of the Specification ends, for example, before it is
determined how a host object would implement the specified [[Get]] method
(as it is free to not follow the specified algorithm then). The
Specification's scope also ends before it is determined how, for a host
object (and even a *native* object), "the next property that does not have
the [[DontEnum]] attribute" is retrieved (as a result, we can observe
different order of for-in iteration in different implementations). However,
that normative algorithm specification does not leave room for a host
object with ECMAScript binding (or a native object) to not implement the
internal [[Get]] method or the [[DontEnum]] property attribute at all.

You aren't very consistent, are you ?

You don't read very carefully, do you?


PointedEars

 

[Thomas 'PointedEars' Lahn]

This is just code. If you want to make a point, you should say what
outcome you did observe when running it, and you should definitely state
in which runtime environment you did observe it.

However, I suppose you wanted to point out that none of those properties

Sorry, here's a jump in thought. Should continue as follows:

....' names occur in the alert() message window.

Nevertheless, hasOwnProperty() has of course nothing to do with the
[[DontEnum]] attribute, so your logic is flawed.

(see ES4F/ES5, section 15.2.4.5.)

As for propertyIsEnumerable(), you *might* have found a *bug* (non-
conforming behavior) instead. (Impossible to tell for sure as you do not
state your test conditions.)


PpintedEars

 

[Thomas 'PointedEars' Lahn]

No. Their existence and behavior is very clearly specified there up to
the point where they must no longer follow the specified algorithms.
for-in includes no such provision.

Should be "need not" (false friends).


PointedEars