423,311 Members | 1,224 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,311 IT Pros & Developers. It's quick & easy.

"Object Expected" error in IE, but no error in Firefox or Opera

P: n/a
When I load the page
<https://bugzilla.mozilla.org/attachment.cgi?id=237739with Internet
Explorer 7 RC 1, I get the error "Object Expected" at line 174. When I
click on the button, I also get the same error on line 186. This same
HTML and JavaScript works perfectly in Firefox and Opera. How can I make
the code work in IE?
Sep 21 '06 #1
Share this Question
Share on Google+
16 Replies


P: n/a

Steve Chapel wrote:
When I load the page
<https://bugzilla.mozilla.org/attachment.cgi?id=237739with Internet
Explorer 7 RC 1, I get the error "Object Expected" at line 174. When I
click on the button, I also get the same error on line 186. This same
HTML and JavaScript works perfectly in Firefox and Opera. How can
I make the code work in IE?
The opening SCRIPT tag uses the TYPE attribute:-

type="application/javascript"

- which is not supported by IE at all. As a result the SCRIPT element's
contents are not processed and all the functions it contains are never
defined. There are the objects that are "expected".

Only changing the value of the TYPE attribute to something IE will
recognise (or removing it entirely) would allow the code to run on IE.

Richard.

Sep 21 '06 #2

P: n/a
Richard Cornford wrote:
The opening SCRIPT tag uses the TYPE attribute:-

type="application/javascript"

- which is not supported by IE at all. As a result the SCRIPT element's
contents are not processed and all the functions it contains are never
defined. There are the objects that are "expected".

Only changing the value of the TYPE attribute to something IE will
recognise (or removing it entirely) would allow the code to run on IE.
You're right. Changing it to type="text/javascript" works. Thanks!

Is there any IETF standard MIME type that will work across all browsers?
Yes, I *am* a hopeless optimist!
Sep 21 '06 #3

P: n/a
Steve Chapel wrote:
Richard Cornford wrote:
The opening SCRIPT tag uses the TYPE attribute:-

type="application/javascript"

- which is not supported by IE at all. As a result the SCRIPT element's
contents are not processed and all the functions it contains are never
defined. There are the objects that are "expected".

Only changing the value of the TYPE attribute to something IE will
recognise (or removing it entirely) would allow the code to run on IE.

You're right. Changing it to type="text/javascript" works. Thanks!

Is there any IETF standard MIME type that will work across all browsers?
Yes, I *am* a hopeless optimist!
Yes "text/javascript". Browsers are either too old to attach meaning to
it, and so ignore it defaulting to javascript, or they assume it to
mean javascript.

Richard.

Sep 21 '06 #4

P: n/a
Steve Chapel wrote:

[snip]
Is there any IETF standard MIME type that will work across all browsers?
Yes, I *am* a hopeless optimist!
There wasn't until April this year (quite a delay, I know). The
text/javascript and text/ecmascript media types are now registered in
RFC 4329, but are obsolete. The application top-level media type
equivalents are preferred, but will be unrecognised in most browsers.

The best choice, for quite a while yet, is text/javascript.

Mike
Sep 21 '06 #5

P: n/a
Michael Winter wrote:
There wasn't until April this year (quite a delay, I know). The
text/javascript and text/ecmascript media types are now registered in
RFC 4329, but are obsolete. The application top-level media type
equivalents are preferred, but will be unrecognised in most browsers.

The best choice, for quite a while yet, is text/javascript.
I thought text/javascript wasn't a registered type, even though lots of
people used it. Did they just register it in April 2006 as an obsolete
type? Just curious.

It looks like text/javascript is the way to go until IE x.x recognizes
application/javascript and earlier versions of IE are nearly unused.
Sep 21 '06 #6

P: n/a
Steve Chapel wrote:

[snip]
I thought text/javascript wasn't a registered type, even though lots
of people used it.
The HTML Recommendation used text/javascript in a script element
example, and that's at least one reason why it became popular. The other
popular type (of Netscape origin, I think) is application/x-javascript,
which some servers use when responding with a script.
Did they just register it in April 2006 as an obsolete type? Just
curious.
Yes. It was obsoleted because the text top-level media type is meant to
represent content that can be read without processing. A script is not
meant for that. It is solely for user agent interpretation.

[snip]

Mike
Sep 21 '06 #7

P: n/a


Michael Winter wrote:

The best choice, for quite a while yet, is text/javascript.
Yes, for scripting HTML documents certainly.

If you script pure SVG documents then text/ecmascript is a better choice
as the SVG specification suggests that and at least one viewer, Apache
Batik (tested here with 1.6), does not want to support text/javascript.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Sep 21 '06 #8

P: n/a
VK

Steve Chapel wrote:
I thought text/javascript wasn't a registered type, even though lots of
people used it.

"type" attribute in <scriptis just a round around way of former
"language" attribute. It means that it is not an equivalent of some
MIME / Content-Type.
All modern browsers do recognize type="text/javascript", so use it.
IE also recognizes type="text/Jscript" (watch the case) and as it's the
only one ever existed browser with JScript, you can use it as a
bulletproof way to execute IE-specific code (ignored by everyone else).
These are two and only content types you have to know for the next
decade.
It looks like text/javascript is the way to go until IE x.x recognizes
application/javascript and earlier versions of IE are nearly unused.
There is no much hope on it (0.01% or less :-) As I said "type"
attribute is not a name of some MIME, just name by itself. The real
MIME type of say JScript is application/x-javascript, this type is
registered on Windows platforms and used internally for WSH files and
bindings. I don't think that Microsoft will break the compatibility for
millions of users for such small and IMO totally artificial issue.

<script type="text/javascript"for everyone everywhere

<script type="text/Jscript"to have it parsed by IE only (if really
needed)

Sep 21 '06 #9

P: n/a

VK wrote:
[...]
All modern browsers do recognize type="text/javascript", so use it.
IE also recognizes type="text/Jscript" (watch the case) and as it's the
only one ever existed browser with JScript, you can use it as a
bulletproof way to execute IE-specific code (ignored by everyone else).
Hardly "bulletproof" for everyone - Firefox is certainly picky about
type attributes, but Safari quite happily executes:

<script type="text/Jscript">
alert('hi');
</script>

I have also had issues where the type attribute is missing, though I've
never been able to create a test case to prove it - it wasn't my code,
so maybe I'm wrong about the cause.
--
Rob

Sep 21 '06 #10

P: n/a
VK
RobG wrote:
Firefox is certainly picky about
type attributes, but Safari quite happily executes:

<script type="text/Jscript">
alert('hi');
</script>
Oh that Safari... :-) :-(
Is there anything this browser (does)&&(does it properly) ? Most of the
time this expression returns false AFAICT.

But you are right, both Safari and Opera do try to execute text/Jscript
as if they indeed had some JScript engine. At the same time Opera
ignores say "text/foobar". So it does recognize the type attribute, it
is just another case of UA spoofing some wannabes are so badly known
for.

So I take my words back about "text/Jscript" bulletproofness. For a
really extended coverage there is only text/javascript with conditional
compilation (IE). I see the most known way right now as
if(window.ActiveXObject), but I wouldn't count on it on a long run:
from my observations as soon as some "reliable" property check goes
into wide use, the spoofing gang adds a loophole for that in their
engines.

Thanks again for your correction.
I have also had issues where the type attribute is missing, though I've
never been able to create a test case to prove it - it wasn't my code,
so maybe I'm wrong about the cause.
You must be thinking of something like:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/vbscript">
MsgBox("Hi!")
</script>

<script>
// IE now expects VBScript code by default,
// so you get "Syntax error" on the next line
window.alert('Hi!');
</script>

</head>

<body>

</body>
</html>

That's a rather artificial issue with a developer explicetly trying to
make UA dizzy (a la the "Korean issue" in IE) yet theoretically
possible.

Sep 22 '06 #11

P: n/a
VK wrote:
RobG wrote:
>Firefox is certainly picky about
type attributes, but Safari quite happily executes:

<script type="text/Jscript">
alert('hi');
</script>

Oh that Safari... :-) :-(
Is there anything this browser (does)&&(does it properly) ? Most
of the time this expression returns false AFAICT.
But your definition of "properly" is not influenced by knowing what
'properly' would be, and instead substituting 'what I expect', which
doesn't count for much.
But you are right, both Safari and Opera do try to execute text/Jscript
as if they indeed had some JScript engine.
Having put considerable effort into making Opera support large chunks
of the IE object model it would be foolish to keep scripts written by
people with foolish notions of supporting IE only from using those
features.
At the same time Opera ignores say "text/foobar". So it does
recognize the type attribute, it is just another case of UA spoofing
some wannabes are so badly known for.
You can not have it both ways. Either browsers adopt Microsoft's de
facto standards, as you assert they should, or they don't. The
consequences of attempting to do so is that scripts that would be
expected to work on IE should work on those browsers as well.
So I take my words back about "text/Jscript" bulletproofness.
You were a fool to say it in the first place, given your well known
ignorance of anything but the most common/obvious browsers.
For a really extended coverage there is only text/javascript with
conditional compilation (IE).
And the more conditional comments re used to keep scripts from browsers
that could cope with them the higher the likelihood becomes that some
other browser will implement them and pretend to be IE. The need to
spoof follows from the attempt to discriminate.
I see the most known way right now as
if(window.ActiveXObject), but I wouldn't count on it on a long run:
You probably see it that way because you are not aware that some
browsers already spoof a global - ActiveXObject - constructor
specifically to defeat that type of browser discrimination (such as
IceBrowser from version 5).
from my observations as soon as some "reliable" property check
goes into wide use, the spoofing gang adds a loophole for that in their
engines.
<snip>

I doubt that your observations have had that outcome (you are not even
capable of observing when and why the scripts you write don't work).
More likely it was people repeatedly pointing it out to you. Otherwise
you would not still be proposing methods of discriminating between
browsers (having understood what it was that made them ineffective).

Richard.

Sep 22 '06 #12

P: n/a
Richard Cornford wrote:
VK wrote:
[snip]
>At the same time Opera ignores say "text/foobar". So it does
recognize the type attribute, it is just another case of UA spoofing
some wannabes are so badly known for.
So MSIE is a wannabe, is it? You do know what "Mozilla/4.0" at the start
of its user agent string refers to, don't you?

[snip]
>So I take my words back about "text/Jscript" bulletproofness.

You were a fool to say it in the first place, given your well known
ignorance of anything but the most common/obvious browsers.
Opera and Safari aren't among the most common or obvious browsers? :-)
>For a really extended coverage there is only text/javascript with
conditional compilation (IE).

And the more conditional comments re used to keep scripts from browsers
that could cope with them the higher the likelihood becomes that some
other browser will implement them and pretend to be IE.
That would probably be a mistake, though. Using condition comments,
rather than parsing hacks, is a sensible way to serve CSS fixes to IE.
If other browsers forge those comments, they're exposing themselves to
content that they really shouldn't process.

I understand your point, and I agree that conditional comments shouldn't
be used for discriminating against the users of other browsers, but it
is useful for fixing bugs that cannot be feature detected.

[snip]

Mike
Sep 22 '06 #13

P: n/a
Michael Winter wrote:
Richard Cornford wrote:
>VK wrote:
<snip>
>>For a really extended coverage there is only text/javascript
with conditional compilation (IE).

And the more conditional comments re used to keep scripts from
browsers that could cope with them the higher the likelihood
becomes that some other browser will implement them and pretend
to be IE.

That would probably be a mistake, though. Using condition
comments, rather than parsing hacks, is a sensible way to
serve CSS fixes to IE. If other browsers forge those
comments, they're exposing themselves to content that they
really shouldn't process.

I understand your point, and I agree that conditional comments
shouldn't be used for discriminating against the users of
other browsers, but it is useful for fixing bugs that cannot be
feature detected.
It will work like everything else has. If it is used to discriminate
between browser it will be rendered ineffective, if it is just used to
address browser specific issues it may never attract any attention. The
more it is proposed as a mechanism for identifying IE the greater the
likelihood that it will be used for discrimination, and so rendered
ineffective over time.

It would have been entirely possible for UA strings to have been
exclusively used for addressing specific browser issues and not to
exclude unexpected browsers. If that had been the case testing UA strings
might still be common (and sensible) practice, instead of the bad joke it
is now.

Richard.
Sep 24 '06 #14

P: n/a
I am having the same problem with the following site that I built:

http://jennafavadesign.com/creative.php

and when you click on any of the images along the right with my imgPop
function. I have all functions listed under my "text/javascript" and
all the other java appears to work fine.

Any thoughts?

Thanks,

Justin

*** Sent via Developersdex http://www.developersdex.com ***
Oct 9 '06 #15

P: n/a
Justin Morabito wrote:
I am having the same problem with the following site that I built:
The same problem as what? The post you have replied to does not mention
any problems at all.
http://jennafavadesign.com/creative.php

and when you click on any of the images along the right with my imgPop
function. I have all functions listed under my "text/javascript" and
all the other java appears to work fine.
You don't think the two syntax errors as the page loads might be
responsible for the functions you later call not existing when you call
them?
Any thoughts?
Try turning script error reporting on, or actually look at the
javascript console and read what it has to say.

Richard.

Oct 9 '06 #16

P: n/a
Justin Morabito wrote:
I am having the same problem with the following site that I built:
What problem?

I think you've replied to the wrong post.
>
http://jennafavadesign.com/creative.php

and when you click on any of the images along the right with my imgPop
function. I have all functions listed under my "text/javascript" and
all the other java appears to work fine.

Any thoughts?
Yes, read what IE's error message tells you: there is an error on line
99, which is:

-->

That appears to be an attempt at an HTML closing comment delimiter. It
is being interpreted by IE as a snippet of (erroneous) global code.
Remove *all* HTML comment delimiters from your script elements and that
issue goes away. They are absolutely *not* needed, especially if you
are intending to use XHTML.

I won't delve into the argument about HTML versus XHTML other than to
say its use on the web is strongly discouraged. Visit an HTML group
and search for threads on HTML versus XHTML, there are many robust
discussions.
--
Rob

Oct 9 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.