developing with / for internet explorer

[GHUM]

Hello,

I created some rather complex Intranet Application, using lots of
JavaScript, DOM-Maninpulation and XMLHTTPRequest communication.

I developed on FireFox, with the excellent firebug ... every misstake
was given back with a fine, fine traceback; exactly pointing to the
code at error.

My code runs fine on FireFox and Opera.

Now some people demand to have that application running with Internet
Explorer; and it fails at the syntax check of the JavaScript. That
surely should be fixable, but the bigger problem is:

Internet Explorer just gives me an error box with some rather bogus
line and character where he detected the error.

Enabling debugging and installing the scriptdebugger from Microsoft
(which, oddly enough, only runs with admin privileges), gives me a
debugging window. And: at each error the MochiKit main JS File is
opened at the beginning.

I am rather sure that the errors are within my JavaScript, not in
MochiKit.

So I am crying out for help: How do you resolve JS errors with Internet
Explorer? Is there any secret weapon to get at least usable line
numbers; or even a traceback of an error?

I do NOT need a full blown debugger, allowing me to single step and
all. Just "this line caused your error" with a usable "this" would be
enough.

Any suggestions?

Harald

 

[Richard Cornford]

GHUM wrote:

Internet Explorer just gives me an error box with some
rather bogus line and character where he detected the
error.

Superficially that is the impression given by the IE error messages.
However, while the error messages do usually show incorrect line
numbers, for example, they are consistently incorrect (as you would
expect from software (consistency not necessarily incorrectness), and
the messages themselves consistently relate to the issue raising the
error, even if they are not always that specific about what the error
is. For example, "xxx.yyy is null or not an object" always means that
xxx did not resolve as a reference to an object so a 'yyy' property
could not be looked up on that object, "object expected" is an attempt
to call a function where the Identifier for the function did not resolve
into an object, and "'xxx' is undefined" is an attempt to reference an
Identifier where the Identifier has not been declared. The messages
themselves may not be particularly obvious but their relationships with
their causes is consistent and can be learnt with experience.

I am rather sure that the errors are within my JavaScript,
not in MochiKit.

Although I would not trust Microsoft's script debugger, I have seen
considerable amounts of time being wasted by people being certain that
the problem did not lie in the locations where automated tools said they
were, and where they actually turned out to be in the long run.

So I am crying out for help: How do you resolve JS errors
with Internet Explorer? Is there any secret weapon to get
at least usable line numbers; or even a traceback of an error?

<snip>

Apart form observing some patterns, such as that errors in event handing
functions internally generated from Intrinsic event attribute values
invariably claim to be on line one, learning which errors are caused by
which issues will tell you what type of thing you are looking for, and
actually locating the offending line can usually be achieved by applying
logic to the question.

Because the error output is consistent, modifying the input and seeing
how the output changes can be used to make deductions about the error's
location. For example, suppose you have an HTML page with embedded
javascript and two imported javascript files, and an error reported on
line 45. If you go to the javascript files and add one blank line to the
top of one and two blank lines to the top of the other and re-load and
reproduce the error, if the line number is now 47 the issue is in the
second javascript files, 46 and it is in the first, and still 45 means
the issue is in the HTML page code, on or about line 45.

Similarly, finding the exact line of code in a javascript file; If the
error report says line 45 the actual error will be in the immediate
vicinity of line 45, but not necessarily on that line. You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Sat, 15
Jul 2006 13:45:06 remote, seen in Richard

Similarly, finding the exact line of code in a javascript file; If the
error report says line 45 the actual error will be in the immediate
vicinity of line 45, but not necessarily on that line. You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.

That's not necessarily the location of the real error; it's the location
where Javascript realises that an error has occurred.

Consider the error of not uncommenting a declaration :

// var x
/* */
x

The error is in the first line, but reported on the third.

I expect other examples can be found in which the actual error is well
before where the presence of an impossibility is detected.

a = b = 1

c = a /* b // but message is clear

 

[Joshua Bell]

That's not necessarily the location of the real error; it's the
location where Javascript realises that an error has occurred.

If only full static analysis was available!

Failing that, jslint is a good tool to have in your arsenal:

http://www.jslint.com/lint.html

Joshua

 

[Randy Webb]

Dr John Stockton said the following on 7/15/2006 6:30 PM:

JRS: In article <[email protected]>, dated Sat, 15
Jul 2006 13:45:06 remote, seen in Richard



That's not necessarily the location of the real error;

If that is your criteria, then you will *never* know the location of the
real error.

it's the location where Javascript realises that an error has occurred.

And that is all you can expect from the browser.

Consider the error of not uncommenting a declaration :

// var x
/* */
x

The error is in the first line, but reported on the third.

Technically speaking, the error is on the third line, not the first. The
first line may be an error by not uncommenting it but having a commented
line is not an error.

But, the above is an example of a human error, not a JS error with
regards to the first/third line.

I expect other examples can be found in which the actual error is well
before where the presence of an impossibility is detected.

Absolutely. Object Expected Line 0 Character 0.

 

[Nicolae Namolovan]

Enabling debugging and installing the scriptdebugger from Microsoft
(which, oddly enough, only runs with admin privileges), gives me a
debugging window. And: at each error the MochiKit main JS File is
opened at the beginning.


Any suggestions?

I have 2 suggestion:
1. Microsoft Script Debugger have a "Call stack" window, check each
item, maybe that will help you to understand what cause the error.
2. Put the "debugger;" line somewhere in the beggining of you
application and execute your application line by line(F8 - Step Into),
this way you must find the exact line of the error.

 

[GHUM]

Richard,

thank you very much for your detailed mail!

Still, within my first reading, I still was hoping that somewhere
around the end you would write something along "ha-ha! I have been
joking! just download IEerrorConsole.activex from somewhere and you are
fine"

However, while the error messages do usually show incorrect line
numbers, for example, they are consistently incorrect

Thanks, that answer alone and the trick with:

Because the error output is consistent, modifying the input and seeing
how the output changes can be used to make deductions about the error's
location.

really helped me to get some steps forward!

is. For example, "xxx.yyy is null or not an object" always means that
xxx did not resolve as a reference to an object so a 'yyy' property
could not be looked up on that object, "object expected" is an attempt
to call a function where the Identifier for the function did not resolve
into an object, and "'xxx' is undefined" is an attempt to reference an
Identifier where the Identifier has not been declared. The messages
themselves may not be particularly obvious but their relationships with
their causes is consistent and can be learnt with experience.

That really helped a lot, thank you! Does somebody know more
translations from "Microsoft" to English? Or German?

I can contribute something: From MochiKit:

GetElementsByTagAndClassName('tag', 'class', parent='content') fails,
not because it is implemented in MochiKit AND in the IE-Javascript, but
because of the parent= ... IE seems not to support named parameters.

You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.

Thanks you very much for pointing this out. It works, thank you!

But I still feel this is so 1980ish to find the offending line via
inserting blanks; especially
knowing that Microsoft is one of the leading suppliers of Software
Development Tools. It's a shame, definitely.

Harald

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Sun, 16 Jul 2006 01:29:28 remote, seen in

Dr John Stockton said the following on 7/15/2006 6:30 PM:

If that is your criteria, then you will *never* know the location of the
real error.

You mean "criterion", the singular form.

It is essential to determine the location of the real error, because
that is where the correction needs to be made.

And that is all you can expect from the browser.

Of course; but Richard's words were claiming that to be the location of
the actual error.

Richard's method, which I sometimes need myself, is good for determining
the line containing the point at which the code ceased to be possibly
valid; that's all.

 

[Richard Cornford]

GHUM wrote:

That really helped a lot, thank you! Does somebody know
more translations from "Microsoft" to English? Or German?

I am not aware of such a list, but part of my pint was that with a good
understanding of how javascript works the actual messages IE issues are
not actually that obscure. For example, when you call a function that is
not declared (say, miss spell/type the function name) Mozilla/Gecko
browser will say - 'xxx' is not a function - while IE will announce
object expected. But when you discover that the offending code is a
function call, and armed with the understanding that functions are
objects and to call a function, so some referenced must be first
resolved into an object _and_then_ that object must turn out to be
callable (have an internal [[Call]] method) it is not so surprising that
IE kicks out an error message at the point of discovering that the
reference did not resolve as an object, and so the message is couched in
terms of object and not functions.

I can contribute something: From MochiKit:

GetElementsByTagAndClassName('tag', 'class', parent='content')
fails, not because it is implemented in MochiKit AND in the
IE-Javascript, but because of the parent= ... IE seems not to
support named parameters.

Named parameters? Javascript (any ECMA 3 rd Ed (or earlier).
implementation, including JScript <= 5.6) has no notion of named
parameters beyond the formal parameter list declarations (a comma
separated list of zero or more Identifiers) that appear in function
declarations and function expressions.

The - parent='content' - above is an assignment expression. It assigns a
string value to a scope-resolved property with the name 'parent', and if
no other object on the scope chain has a property called 'parent' it
will be resolved as the 'parent' property of the global/window object.
It is normal for browser environment hosts to provide a 'parent'
property of the global/window object that is used to hold a reference to
the global/window object of the frame containing the (first)
global/window object's frame in a frameset, or the current global/window
if there is no frameset (or IRAMEs in the parent). This is why IE is
complaining as it does not allow this value to be re-assigned (and it is
optionally allowed to do that by specification).

Assignment expressions are allowed in the arguments list used in a
(function) call expression, indeed the (optional) ArgumentsList is
formally defined as a comma separated list of one or more
AssignmentExpressions, though the AssignmentExpression is a category of
expressions that goes well beyond actual assignment operations. In a
call expression the AssignmentExpressions are evaluated and it is the
result of that evaluation is passed to the function call as its
argument. An assignment operation evaluates as the value assigned so -
parent='content' evaluates as the string 'content', and the assignment
of the value to the 'parent' property of some object on the scope chain
is a side effect (desirable or otherwise).

If the notion here is that the Identifier - parent - can then be used
within the function called to refer to the argument then in may cases it
can, but the mechanism then has nothing to do with the arguments to the
function call. Instead the side effect of assigning the value to what is
in effect a global variable is mirrored by the fact that the use of an
undeclared (as a formal parameter, inner function declaration or local
variable name) Identifier will also result in resolution against the
scope chain with a high probability of the result being a reference to
the same global variable as the value had been written to during the
evaluation of the arguments to the function call. So once again a
misconception about how javascript works can avoid being exposed because
the code that employs it seems to 'work', at least up to the point where
it doesn't work.

It worries me that you have described this as 'named parameters' and I
wonder where you got that idea. I hope that the alarm bells are now
ringing and you can now see that you have identified a source of
information that is not reliable (is fundamentally mistaken about the
nature of javascript). You have not explained what this 'MochiKit' is,
or what relevance it has, but if it is the source of the 'named
parameters' suggestion you need to be questioning the competence of the
people responsible.

But I still feel this is so 1980ish to find the offending
line via inserting blanks;

I tend to be pragmatic, if something tells me what I need to know in
return for (literally in most cases) a few seconds work then I am not
going to worry that it doesn't seem so sophisticated.

especially knowing that Microsoft is one of the leading
suppliers of Software Development Tools. It's a shame,
definitely.

Remember the role of marketing in business. It is not about finding out
what people what, it is about finding out how little can be got away
with, because no business can make a profit by giving people what the
want. Microsoft is a very successful business.

Richard.

 

[GHUM]

Richard,

while IE will announce object expected. But when you discover that
the offending code is a
function call, and armed with the understanding that functions are
objects and to call a function, so some referenced must be first
resolved into an object _and_then_ that object must turn out to be
callable (have an internal [[Call]] method) it is not so surprising that
IE kicks out an error message at the point of discovering that the
reference did not resolve as an object, and so the message is couched in
terms of object and not functions.

Thank you very much for this explanation! You did not give me
additional vocabulary, but instead gave me an insight into the grammar
That way of thinking will really help.

Named parameters? Javascript (any ECMA 3 rd Ed (or earlier).
implementation, including JScript <= 5.6) has no notion of named
parameters beyond the formal parameter list declarations (a comma
separated list of zero or more Identifiers) that appear in function
declarations and function expressions.

Uuups. So I just happened to abuse an assignment. Those "named
parameters" come from Python, where I do most of my development.
I grew to use those named parameters, because they help me understand
function calls years after the initial development of them.

It is normal for browser environment hosts to provide a 'parent'
property of the global/window object that is used to hold a reference to
the global/window object of the frame containing the (first)
global/window object's frame in a frameset, or the current global/window
if there is no frameset (or IRAMEs in the parent).

Good. So if in the interface description somebody would have named the
3rd parameter "upperlevelelement" or similiar, I would not have
stumbled accross that error for ages.

It worries me that you have described this as 'named parameters' and I
wonder where you got that idea.
You have not explained what this 'MochiKit' is,
or what relevance it has,

MochiKit is definitely not the "source" of that "named parameters"
idea. Those "parameter names" are used for the interface description,
giving something like:

getElementsByTagAndClassName(tag,class,[parent])

which is a rather usual description of a function interface. It was
clearly my mistake to keep the "parent"... the reasoning was: "of
course parameter 1 is a TAG, and 2 is a CLASS... if the function is
called "by Tag and Class". But will I really know what the 3rd
parameter is on first sight after 6months? So to save me from looking
up the definition, I used this "named parameter", and it worked out
fine. Or rahter, it seemed to work out fine. MochiKit itself is a
really well documented JavaScript library at www.mochikit.com;
developed mainly by Bob Ipollito.

And clearly, there is no suggestion that "you can use named parameters
with Javascript" anywhere in MochiKit. Just those innocent and usual
Api-definitions.

The only thing MochiKit would be to "blame" of is that it makes
JavaScript often feel like Python - which is feel as a good thing,
because it makes me feel at home. So, feeling "at home" I did as I do
"at home".

Thanks again for that explanation, and in the long run I am happy to
have tried to use "named parameters", because it gave me the
opportunitie to learn a lot by reading your explanation.

Harald

 

[Richard Cornford]

Richard,

while IE will announce object expected. But when you discover
that the offending code is a function call, and armed with the
understanding that functions are objects and to call a function,
so some referenced must be first resolved into an object
_and_then_ that object must turn out to be callable (have an
internal [[Call]] method) it is not so surprising that IE kicks
out an error message at the point of discovering that the
reference did not resolve as an object, and so the message is
couched in terms of object and not functions.

Thank you very much for this explanation! You did not give me
additional vocabulary, but instead gave me an insight into the
grammar That way of thinking will really help.

In terms of English I made a bit of a hash out of the grammar in that
paragraph (comes of trying to write posts well after I should have gone
to bed).

Uuups. So I just happened to abuse an assignment. Those "named
parameters" come from Python, where I do most of my development.
I grew to use those named parameters, because they help me understand
function calls years after the initial development of them.


Good. So if in the interface description somebody would have
named the 3rd parameter "upperlevelelement" or similiar, I would
not have stumbled accross that error for ages.

Yes, assigning to 'upperlevelelement' would be very unlikely to provoke
any complaints from web browsers (except Gecko browser's "warnings",
and as many of those are utterly bogus (particularly in cross-browser
scripting) they are best turned off).

It worries me that you have described this as 'named parameters'
and I wonder where you got that idea. You have not explained what
this 'MochiKit' is, or what relevance it has,

MochiKit is definitely not the "source" of that "named parameters"
idea. Those "parameter names" are used for the interface description,
giving something like:

getElementsByTagAndClassName(tag,class,[parent])

which is a rather usual description of a function interface. It was
clearly my mistake to keep the "parent"

It was probably a mistake to have the 'parent' there in the first place
as it is ambiguous in a browser object model where numerous
parent-child relationships exist (including the frame/frameset
relationships). Something like 'parentElement' would seem more clear,
except that the value being passed in is a string, which is assume is
an ID string for an element, and so 'parentElementId' would probably be
the name that states what the parameter actually is. Then again, if
this function works like - getElementByTagName - then maybe
'ancestorElementID' would be better yet as the IDed element will not
necessarily be the 'parent' of the elements returned.

... the reasoning was: "of course parameter 1 is a TAG, and 2 is
a CLASS... if the function is called "by Tag and Class". But will I
really know what the 3rd parameter is on first sight after 6months?

Which is fine so long as in 6 months time you don't have a better
appreciation of the browser DOM and find yourself wondering what this
'parent' has to do with the containing frame.

So to save me from looking
up the definition,

Generally, it should never be too much effort to cross-reference a
function call with the function definition, where the meaning of the
parameters (if not completely obvious) should be the subject of
comments. Javascript projects are rarely that big that locating the
code for a function definition is a major undertaking.

I used this "named parameter", and it worked out
fine. Or rahter, it seemed to work out fine.

Javascript can be like that; lots of things 'work', or seem to 'work',
while not doing what the expectation that motivated them thinks they
should be doing. If you look you will see plenty of 'mystical
incantations' appearing in published javascript code, with there
authors very reluctant to expand on their motivations for using them.

MochiKit itself is a really well documented JavaScript library at
www.mochikit.com; developed mainly by Bob Ipollito.

Fair enough, but bare in mind that there is an inverse relationship
between an individuals understanding of javascript (particularly in
relation to Internet browser scripting) and their tendency to use
large, interdependent javascript libraries (well documented or
otherwise). They are too self-evidently a poor approach to issues of
browser scripting so with the understanding comes a quest for a more
appropriate strategy to code re-use.

The only thing MochiKit would be to "blame" of is that it
makes JavaScript often feel like Python - which is feel as
a good thing, because it makes me feel at home. So, feeling
"at home" I did as I do "at home".

<snip>

Probably the one factor that has resulted in the creation of more bad
javascript than any other is its ability to faster a sense of over
confidence in near-novices.

Personally, I think it is a mistake to try to make javascript seem like
any language that is not javascript. Javascript is sufficiently
flexible that in many respects it is possible to do that (or give the
illusion of having done that), but the more successful the attempt the
more the programmers of those other languages will bring in
expectations that will often be ultimately disappointed and prior to
that will act to keep them from understanding javascript for what it
is.

Richard.

 

[Randy Webb]

Dr John Stockton said the following on 7/16/2006 3:25 PM:

JRS: In article <[email protected]>, dated
Sun, 16 Jul 2006 01:29:28 remote, seen in

You mean "criterion", the singular form.

No, I meant what I typed.

It is essential to determine the location of the real error, because
that is where the correction needs to be made.

That is for the programmer, not the browser to determine.

Of course; but Richard's words were claiming that to be the location of
the actual error.

Umm, because that *is* where the actual error is *to the parser*.

Richard's method, which I sometimes need myself, is good for determining
the line containing the point at which the code ceased to be possibly
valid; that's all.

And that's all you can depend on the browser to tell you.