Crashing IE 6

[Asen Bozhilov]

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.

Documentation is clear about my code, if `propertyIsEnumerable' return
primitive boolean value `true' for passed property name, that property
should be enumerate during `for-in` evaluation. `propertyIsEnumerable'
doesn't analyze prototype chain for that property.
`propertyIsEnumerable` return true only if object has own property
with that name and that property doesn't have attribute {DontEnum}.
Environment in which you can observe that behavior is Mozilla Firefox
3.6.3.

Do you think `for-in` with host object is reasonable development? If
true, please provide your arguments and for better discuss stop using
words: "Nonsense", "Gibberish" and so on, because with words like
these you don't approve anything. Thanks.

 

[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
Nevertheless, hasOwnProperty() has of course nothing to do with the
[[DontEnum]] attribute, so your logic is flawed.

Documentation is clear about my code,
No.

if `propertyIsEnumerable' return primitive boolean value `true' for
passed property name, that property should be enumerate during `for-in`
evaluation.

Of course. But you did not state the outcome, nor did you state the test
conditions so that your observations could be confirmed. So the code as
posted was worthless, and the documentation, as you prefer to call it, was
insufficient and not clear at all.

`propertyIsEnumerable' doesn't analyze prototype chain for that property.

I did not say it was.

`propertyIsEnumerable` return true only if object has own property
with that name and that property doesn't have attribute {DontEnum}.
Environment in which you can observe that behavior is Mozilla Firefox
3.6.3.

As I said, if that is so then you have found a bug (non-conforming
behavior) in that implementation or runtime environment instead. You have
_not_ found proof for your misconception that the specified for-in
algorithm does not apply to host objects, or your other misconceptions.

Do you think `for-in` with host object is reasonable development?

Mu.


PointedEars

 

[Michael Haufe (\TNO\)]

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?

The former.

 

[RobG]

Did you misspell aghast?  

No, they seem to think it's an incredibly clever piece of code. I'm
aghast at the clueless responses.

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.

Sorry to say but that attitude is very old-school. A recent survey
here found that 70% of news articles are sourced from PR releases.
"Journalists" are now filter-feeders, not hunter-gatherers.

[...]

 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).

The site were I work still uses IE 6, mostly because they wrote a
number of internal applications that are dependent upon it and their
programmers still think that it is impractical to write cross-browser
applications. It is a reflection of their own ignorance and pretty
revealing of the incompetence of their management who don't see either
issue and are therefore unable to fix them.

A large number of government departments are in the same boat, it will
be interesting to see what will be the catalyst to get them to
upgrade, probably something obtuse like a version of SQL Server or
Sharepoint that is no longer compatible with XP, should MS ever have
the front to try it.

 

[David Mark]

No, they seem to think it's an incredibly clever piece of code. I'm
aghast at the clueless responses.

Well, what else is new? It's amazing that a script that is so
thoroughly incompetent with regard to IE (particularly 6, 7 and
Compatibility View in 8) could somehow sell the idea that it is all
Microsoft's fault. I suppose MS is any easy target.

Sorry to say but that attitude is very old-school. A recent survey
here found that 70% of news articles are sourced from PR releases.
"Journalists" are now filter-feeders, not hunter-gatherers.

I understand that, but the Ajaxian duo know about My Library (and have
for some time). You'd think if they cared about their readers at all,
they would have managed to come up with a few paragraphs. Instead, they
focus on things like snowflake scripts and browser crashers.

[...]

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).

The site were I work still uses IE 6, mostly because they wrote a
number of internal applications that are dependent upon it and their
programmers still think that it is impractical to write cross-browser
applications.

Pragmatic.

It is a reflection of their own ignorance and pretty
revealing of the incompetence of their management who don't see either
issue and are therefore unable to fix them.

That's pretty typical. If the programmers are just "sure" that a task
is impossible, management is hardly in a position to argue with their
chosen "experts".

A large number of government departments are in the same boat, it will
be interesting to see what will be the catalyst to get them to
upgrade, probably something obtuse like a version of SQL Server or
Sharepoint that is no longer compatible with XP, should MS ever have
the front to try it.

Banks too. Yet the more "pragmatic" in this industry call for IE6 to be
"abolished". It's hard to believe such people are on the same planet,
much less in the same industry. I bump into these sorts from time to
time and they are usually as insufferable as they are incompetent. The
typical subject is 20-something, reads Ajaxian religiously, has a really
bad haircut and a penchant for making stupid and thoughtless remarks.

Here are some excerpts from my upcoming "J is for Junk" primer. In the
context of technical discussions, these are some of the remarks that
should throw up big red flags (but often don't):

On JS:

* "JavaScript (sic) is buggy."
" "JS is old-school."
* "Nobody should have to write JS in 2010!"
* "Why don't we all program in assembly language?"
* "CLJ is full of trolling snarks. Read the Dojo mailing list instead."

On libraries:

* "Library ABC is very popular."
* "Library ABC has been around for a long time."
* "People write books about Library ABC."
* "People write blog posts about Library ABC."
* "Library ABC offers frequent upgrades."
* "Library ABC is too cross-browser."
* "Library ABC works in _all_ browsers!"
* "Library ABC just works."
* "Library ABC seems to work in our supported browsers."
* "Library ABC is all about progressive enhancement."
* "Library ABC is well-tested."
* "Library ABC is well-supported."
* "Library ABC means less typing."
* "Library ABC saves us time and money."
* "First thing we have to do is choose a library."
* "Why aren't you using a library?"
* "We'll just upgrade!"
* "Then we won't upgrade."
* "Aw, UR just jealous coz nobody uses your library."

On browsers:

* "We don't care about browser XYZ."
* "Nobody uses browser XYZ."
* "Browser XYZ is ancient."
* "It's a waste of time to test in browser XYZ."
* "Why don't we try to support IE3 while we are at it?"
* "If browsers lie about their UA string, that's their problem."

On users:

* "Nobody disables scripting."
* "If the user disables scripting it's their fault."
* "If the user has a small monitor it's their fault."
* "If the user is blind it's their fault."
* "If the user is spastic it's their fault."
* "If the user doesn't upgrade their browser it's their fault."
* "If the user doesn't upgrade their OS it's their fault."
* "If the user changes their UA string it's their fault."
* "Who doesn't have a mouse?"

On logic:

* "Show me where it fails."
* "Good enough for Google!"
* "I'm just not good with abstractions."

On philosophy:

* "We're being pragmatic."
* "Nothing is guaranteed." (as an excuse to do obviously stupid things)
* "That won't work in the Real World."
* "That won't work in a Serious Framework."
* "We don't want to reinvent the wheel."

On markup:

* "XHTML is better."
" "Always put SCRIPT elements in the HEAD."
" "Always put SCRIPT elements at the end of the body."
* "SCRIPT elements in the BODY are bad for progressive enhancement."
* "Validation doesn't matter."
* "Validation is a waste of time."

And so on, and so on...

 

[Dmitry A. Soshnikov]

[...]

On JS:

* "JavaScript (sic) is buggy."

Every technology has "buggy" things by some alternative viewpoint. So
it is relatively. Don't listen them.

" "JS is old-school."

Yes, of course, but it continues its evolution and development. If
stop, it will gone.

* "Nobody should have to write JS in 2010!"
Lie.

* "Why don't we all program in assembly language?"

That's the main point of all the list you wrote. It's the question of
an *abstraction* (of increasing of the abstraction of every new
level). Any new technology provides its own level of abstraction and
users of that technology have all rights do not think about previous
level of abstraction.

I wrote this sentences on many forums and some years ago, that it was,
is and will be so always. That some professional on current
abstraction level will always "defense" his current abstraction level
(which of course always will becoming an "old-school" if won't
evaluate, thought, yet it is not about ES) and see errors/mistakes/non-
efficient constructions and designs of a *new* abstraction level.

That is absolutely the same. You don't speak about how e.g. this or
that ES *implementation* is written. Because you're free from that
abstraction layer/level. The same with users of libraries. And after
that will be users of "Super New <LibraryName> 1.5" which will be
written on that "<LibraryName>" with file size 5Gb; and professionals
from previous abstraction layer will see errors/mistakes/
misconceptions of that "Super New <LibraryName> 1.5".

And it was so, is so and will be always so. Because this exactly is
called as a "progress" (independently some concrete implementation or
library, I'm talking in general). And this progress always get more
resources which are "equalized" and "smoothed" on the new hardware.

The main and the general way of programing languages - is *increasing
of abstraction*.

Because when some see:

mov ah, 09h
mov dx, offset someString
int 21h

they don't say: "let's put 09h value into the `ah` register, and then
put offset (load effective address) of someString, and then call 21st
interruption". But they instead say: "let put this in some useful
wrapper and call it as `print` - then we can concentrate on more art
tasks and do not thinks about implementation of that `print`. Yes, of
course it will be less effective because of many checks inside (read,
providing cross-browsing), but we'll get *another increased level of
abstraction* when there is concept of a `print` and we don't think
about what is this".

* "CLJ is full of trolling snarks.

Yes, unfortunately, that's true. But, everything can be changed

Read the Dojo mailing list instead."

Don't know.

And so on, and so on...

All other cites have consequences from my previous explanation, so it
applies to them also.

Dmitry.

 

[Asen Bozhilov]

David Mark wrote:

Every technology has "buggy" things by some alternative viewpoint. So
it is relatively. Don't listen them.

At all you are correct, but David point is how people misunderstood
the concept things in browser scripting. That is usually answer when
the person misunderstood the language and concept. Some people when
mistake, they found good justification in sentence: "The language is
buggy". Perhaps every programming language is designed by people who
know what are they doing. So the language isn't buggy. The bug is
usually at developer brain.

Lie.

It's typical answer given by "Framework monkeys". They just get the
new version of some framework and think "That framework is very cool",
which isn't thinking of professional developer.

<snip>

Again you are correct, but again that is typical answer on question:
"Why that program is performance and memory shock?", and given answer
is: "What do you want?!? If you want performance rewrite on assembly
language!". No, I just want good program. I don't need to change
language. I just want to use the power of environment and power of JS.
That is all.

 

[David Mark]

[...]

On JS:

* "JavaScript (sic) is buggy."

Every technology has "buggy" things by some alternative viewpoint. So
it is relatively. Don't listen them.

I don't listen to them. I think you missed the mocking tone of these
quotes. And, relatively speaking, JS can hardly be considered buggy.
It's the DOM implementations that many people parrot about, which (at
least in the major browsers) are fairly stable and consistent these days
as well. The people being parroted are thinking of five years ago when
this whole GP library craze began.

Yes, of course, but it continues its evolution and development. If
stop, it will gone.

Again, I think you missed the point. This is usually said in defense of
bad scripts like jQuery (which is considered "new wave", despite the
Devo hat in the logo).

Lie.

At best it is confused.

That's the main point of all the list you wrote. It's the question of
an *abstraction* (of increasing of the abstraction of every new
level). Any new technology provides its own level of abstraction and
users of that technology have all rights do not think about previous
level of abstraction.

I'm all for higher-level abstractions as long as they are built on solid
lower-level abstractions. Unfortunately, most popular JS libraries have
not fit this description to date.

[...]

Yes, unfortunately, that's true. But, everything can be changed

Is snark even a proper word? ISTM it was the name of a creature in one
of those Alice in Wonderland books.

Don't know.

Don't do it unless you like misinformation. And certainly don't use the
Web interface (which uses jQuery) with Opera.

 

[Dmitry A. Soshnikov]

[...]

I think you missed the mocking tone of these
quotes.

No, no, that exactly I meant. That these quotes can be absolutely
*correct* (without any humor) and at the same time -- not (if we will
talk about exactly JS abstraction). But users of libraries (as the
same you -- a user of ECMAScript programming language -- which is a
very high abstraction in contrast with e.g. C or Assembler) have all
rights do not even *think* about some previous abstraction levels.
Only if they interested in them, that's another question.

So the main point of this question is in the *point of view* on all
these talks, discussions, defenses of something and so on. You think
that in the past some Assembler programmers didn't talk something like
"WTF is C? That's slow crap? Don't use it "C Monkeys", use old good
Assembler". But this meaning hardly can be named as advanced
professional. What the most funny, Assembler itself is already a very
high abstraction (before it there are HEX- and BIN- codes programming
(which are also very high abstractions, because human can understand
it), and before that -- programming with cords).

What benefits will some have if he know some previous abstraction
level? Of course benefits are obvious. You can more powerfully use the
system, implement additional stuff (e.g. my C++ colleague which wrote
some additional modules for SpiderMonkey on C in my previous project
-- so we have some augmented SpiderMonkey engine), to repair if
something will go wrong on "low" abstraction level and so on.

But that doesn't mean that user of some concrete abstraction layer
should know all the stuff of previous level. Otherwise, the fair
question will be about all other previous abstraction levels (do you
program every day on HEX-codes? I mean not to pass the exams in the
University, but -- every day and spread it as the only one correct way
and all others -- are "monkeys"? I guess not).

So we use some our level of abstraction + - some previous and (of
course) should know about all future levels. When we see that line of
code:

alert(1);

we don't even think about all needed layers of abstraction to build
this fancy modal window (but think how many of the them are used), for
us it is simply and abstract -- "show us a message" (the analogue with
the `print` on Assembler from the previous message) and we can
concentrate on more art tasks.

That exactly with users of some libraries which provide additional
abstraction level. You know deeply JavaScript itself? -- that's
brilliant, then you can understand and use for full force that new
abstraction layer (or again -- to repair something on low level). You
know deeply C? -- No? -- then you can't repair some buggy
implementation. But other will and tell you how ugly is JS written
itself on low level. And so on, and so forth.

So as I see the professional viewpoint -- is that you deeply know and
understand your abstraction level (that one which you use on practice
every day, e.g. JavaScript). All other abstraction levels -- are by
the own wish. If you know some nearest previous abstraction levels --
this is very good (e.g. if user of jQuery knows JavaScript). But (the
most important point) -- if you stop on some current level and will
talk "don't use that new crap", you can loose. So we should know all
new (neighbor) layers and go forward. If want say for users of some
new abstraction level that something is written bad, you can; some of
them (which are interested in your abstractions level) will be
thankful to you, but all other have complete rights do not think about
it.

I'm all for higher-level abstractions as long as they are built on solid
lower-level abstractions.  Unfortunately, most popular JS libraries have
not fit this description to date.

That's the point, nobody's limit you to use anything to implement you
abstraction level. E.g. you library could be written on pure hex-
codes. Will it be better?

Today programming languages (becoming high-level abstracted) still are
very low abstracted (and JavaScript also). We still should type
something with hands I think in future will appear new concepts and
paradigms, and if stop on our current level and will claim everything
which is less effective (because we see how it is built inside), we
loose -- that was, is and always will be so. But, that mostly about
philosophy

P.S. And by the way, Assembler still rocks And besides of funny
applications (e.g. demo scenes which I like very much when some
amazing graphics and sound are written only in 64Kb (exactly 65536
bytes) or even 4Kb) there is a huge serious approach e.g. programming
of micro controllers and so on.

Dmitry.

 

[Dmitry A. Soshnikov]

At all you are correct, but David point is how people misunderstood
the concept things in browser scripting. That is usually answer when
the person misunderstood the language and concept. Some people when
mistake, they found good justification in sentence: "The language is
buggy". Perhaps every programming language is designed by people who
know what are they doing. So the language isn't buggy. The bug is
usually at developer brain.



It's typical answer given by "Framework monkeys". They just get the
new version of some framework and think "That framework is very cool",
which isn't thinking of professional developer.


<snip>

Again you are correct, but again that is typical answer on question:
"Why that program is performance and memory shock?", and given answer
is: "What do you want?!? If you want performance rewrite on assembly
language!". No, I just want good program. I don't need to change
language. I just want to use the power of environment and power of JS.
That is all.

Yes, I of course understand what do all that questions/answers mean
(and from which audience we can hear them). But showed another "point
of view" what is the most important thing.

Dmitry.

 

[Michael Haufe (\TNO\)]

I'm all for higher-level abstractions as long as they are built on solid
lower-level abstractions.  Unfortunately, most popular JS libraries have
not fit this description to date.

The key being "higher-level". I have seen a tendency for abstracting
sideways in some of these techniques, which obfuscates instead of
enlightening.

 

[Michael Haufe (\TNO\)]

Today programming languages (becoming high-level abstracted) still are
very low abstracted (and JavaScript also). We still should type
something with hands I think in future will appear new concepts and
paradigms, and if stop on our current level and will claim everything
which is less effective (because we see how it is built inside), we
loose -- that was, is and always will be so. But, that mostly about
philosophy

I think it's more telling that of all the dozens of paradigms
discovered thus far, we still fall back to imperative/declarative/
functional hand typing. Notice that 5th generation languages never had
much success.

 

[John G Harris]

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.

<snip>

So, you are saying that there is a programming language that can
manipulate host objects as well as do anything that ECMAScript can do.

We call that language javascript, and we don't care if Thos. Lahn
doesn't like the name.

John

 

[RobG]

On Apr 4, 6:47 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
[...]

[Host object] behavior is evidentially (sic!) specified by ECMA-262 up toa 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.

It seems to me that if there is a host method, such as getElementById,
that has no specified properties and where the particular
implementation does not allow users to add their own properties, that
there is no need for that method to have either internal [[Get]] or
[[Put]] methods.

Or is it that however the UA handles such cases (other than crashing)
for those methods *is* its [[Get]] method? For the relevant part of
ECMA-262 ed 3, IE should get to step 5 then go straight to step 14.

1. Evaluate the Expression.
2. Call GetValue(Result(1)).
3. Call ToObject(Result(2)).
4. Let V = empty.
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.
....
14. Return (normal, V, empty).

 

[Thomas 'PointedEars' Lahn]

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.

So, you are saying that there is a programming language that can
manipulate host objects as well as do anything that ECMAScript can do.

ECMAScript *is* a programming language, so it or its conforming
implementations (like JavaScript) can manipulate host objects
that have an ECMAScript binding defined.

We call that language javascript, and we don't care if Thos. Lahn doesn't
like the name.

What you have is curable, you know.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[Host object] 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.

It seems to me that if there is a host method, such as getElementById,
that has no specified properties and where the particular
implementation does not allow users to add their own properties, that
there is no need for that method to have either internal [[Get]] or
[[Put]] methods.

I agree. However, that reasoning is irrelevant with regard to for-in
iteration on host object's methods and the observed "crash", as the
relevant algorithms do not require their [[Get]] or [[Put]] method to be
called.

It is important to understand that the internal [[Get]] method is a mere
specification mechanism for the corresponding steps in the specified
algorithms to make sense. Likewise for other internal methods and the
property attributes. This is particularly visible with host objects as
they do not need to implement that method according to the algorithm
specified for it. Therefore, saying that host objects need to implement
those methods and attributes merely means that they need to work as (far
as) specified. Which for [[Get]] merely means that it is an implementation
of an algorithm that when given a "PropertyName" it would "[return] the
value of the [corresponding] property."

I can see two approaches to understand how for-in iteration works for host
objects. One, to assume that it does not apply to host objects because
they do not need to be of the Object type, and, as a result, do not (need
to) implement the [[DontEnum]] property attribute. Two, to assume that the
algorithm applies to all objects, including host objects, and that
therefore all objects must implement the concept of [[DontEnum]]. It is
not reasonable for me to subscribe to the first assumption, not least
because we have to assume that many if not all host objects must be of the
Object type in a conforming implementation. Otherwise it would not be
possible to use those objects in contexts in which they are known to be
usable and useful.

So there is a need for the host object referred to by _`document'_ to
*implement* (the concept of) the [[Get]] method, and for the host object
referred to by `document.getElementById' to implement the internal [[Call]]
method, or the former object could not have a `getElementById' method to be
called for it without throwing a TypeError, and as a result that method
would be utterly useless. This is the practical outcome of the theoretical
requirements set by the algorithms of the Language Specification.

Or is it that however the UA handles such cases (other than crashing)
for those methods *is* its [[Get]] method? For the relevant part of
ECMA-262 ed 3, IE should get to step 5 then go straight to step 14.
[...]

Parse error.


PointedEars

 

[John G Harris]

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.

So, you are saying that there is a programming language that can
manipulate host objects as well as do anything that ECMAScript can do.

ECMAScript *is* a programming language, so it or its conforming
implementations (like JavaScript) can manipulate host objects
that have an ECMAScript binding defined.

We call that language javascript, and we don't care if Thos. Lahn doesn't
like the name.

What you have is curable, you know.

What I have is common sense, and, no, it is not curable.

John