ASPX, VBScript, JavaScript, Double-Underscored Variables and setTimeOut

S

Shadow Lynx

That subject packs a whallop, so let me explain in better detail what's
happening and how it relates to ASPX pages...

In a [large] nutshell, if the first <script /> on a page is of type
"text/vbscript", you cannot use inline JavaScript statements that call
setTimeout with functions that start with a double-underscore. This is
very relavant to ASPX (ASP Dot Net) pages because it means that
AutoPostBacks will fail since they generally call the famous JavaScript
statement "__doPostBack(...)" via a setTimeout call.

If you include a VBScript code block before any other code block on an
ASPX page, the following statement will fail in IE (and the error is
far from obvious since it is untrappable and says only that there is an
Invalid character on line 1, character 2):

"javascript:setTimeout('__doPostBack(\'anyASPXcontrol\',\'\')', 0)"

This is a bug in IE 6 and possibly earlier versions (I only have v6 to
play with.) I do not know if it affects IE 7 as I have not installed
that for testing lately. Note that even though the prefix of
"javascript:" is used, the setTimeout function assumes it's calling a
VBScript function, presumably because the first script block is a
VBScript block.

Here is a very simple page that shows this bug:
http://www.digitolle.net/news/testscriptbug.htm

and here is the source code:

--------

<html>
<head>
<title>Test Script Bug</title>
<!-- script type="text/javascript">
// If JavaScript is the first script, setTimeout works properly
// Unrem this script and both buttons will work.
</script -->
<script type="text/vbscript">
' Just because this VBScript block exists,
' setTimeout uses VBScript naming conventions.
' Therefore, double underscore functions will fail
' Rem this block out, and both buttons will work
' Note that calling the function directly always works.
</script>
</head>
<body>
<script type="text/javascript">
function __x() {
alert("test");
}
</script>
<input type="button" value="This will Work"
onclick="javascript:__x();" />
<br />
<input type="button" value="This will Fail"
onclick="javascript:setTimeout('__x()', 0);" />
</body>
</html>

--------

The obvious workaround is to always include a JavaScript block before
any VBScript blocks, even if it's just an empty block. If anyone else
comes up with the same results on this test, please let me know. Of
course if this is a known issue and I'm beating a dead horse, again,
please let me know because it's an odd issue to look up and it's
definitely a brain stumper if you don't know it exists.
 
G

Guest

Have you tried setting an emtpy javascript <script... tagset at the beginning?
I seem to recall this as a fix.
peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com




Shadow Lynx said:
That subject packs a whallop, so let me explain in better detail what's
happening and how it relates to ASPX pages...

In a [large] nutshell, if the first <script /> on a page is of type
"text/vbscript", you cannot use inline JavaScript statements that call
setTimeout with functions that start with a double-underscore. This is
very relavant to ASPX (ASP Dot Net) pages because it means that
AutoPostBacks will fail since they generally call the famous JavaScript
statement "__doPostBack(...)" via a setTimeout call.

If you include a VBScript code block before any other code block on an
ASPX page, the following statement will fail in IE (and the error is
far from obvious since it is untrappable and says only that there is an
Invalid character on line 1, character 2):

"javascript:setTimeout('__doPostBack(\'anyASPXcontrol\',\'\')', 0)"

This is a bug in IE 6 and possibly earlier versions (I only have v6 to
play with.) I do not know if it affects IE 7 as I have not installed
that for testing lately. Note that even though the prefix of
"javascript:" is used, the setTimeout function assumes it's calling a
VBScript function, presumably because the first script block is a
VBScript block.

Here is a very simple page that shows this bug:
http://www.digitolle.net/news/testscriptbug.htm

and here is the source code:

--------

<html>
<head>
<title>Test Script Bug</title>
<!-- script type="text/javascript">
// If JavaScript is the first script, setTimeout works properly
// Unrem this script and both buttons will work.
</script -->
<script type="text/vbscript">
' Just because this VBScript block exists,
' setTimeout uses VBScript naming conventions.
' Therefore, double underscore functions will fail
' Rem this block out, and both buttons will work
' Note that calling the function directly always works.
</script>
</head>
<body>
<script type="text/javascript">
function __x() {
alert("test");
}
</script>
<input type="button" value="This will Work"
onclick="javascript:__x();" />
<br />
<input type="button" value="This will Fail"
onclick="javascript:setTimeout('__x()', 0);" />
</body>
</html>

--------

The obvious workaround is to always include a JavaScript block before
any VBScript blocks, even if it's just an empty block. If anyone else
comes up with the same results on this test, please let me know. Of
course if this is a known issue and I'm beating a dead horse, again,
please let me know because it's an odd issue to look up and it's
definitely a brain stumper if you don't know it exists.
 
G

Guest

Sorry, I see you've done that. The piece I remember reading said that the
script engine is initialized by the empty script set. No workaround was
provided, that "is" the workaround.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com




Shadow Lynx said:
That subject packs a whallop, so let me explain in better detail what's
happening and how it relates to ASPX pages...

In a [large] nutshell, if the first <script /> on a page is of type
"text/vbscript", you cannot use inline JavaScript statements that call
setTimeout with functions that start with a double-underscore. This is
very relavant to ASPX (ASP Dot Net) pages because it means that
AutoPostBacks will fail since they generally call the famous JavaScript
statement "__doPostBack(...)" via a setTimeout call.

If you include a VBScript code block before any other code block on an
ASPX page, the following statement will fail in IE (and the error is
far from obvious since it is untrappable and says only that there is an
Invalid character on line 1, character 2):

"javascript:setTimeout('__doPostBack(\'anyASPXcontrol\',\'\')', 0)"

This is a bug in IE 6 and possibly earlier versions (I only have v6 to
play with.) I do not know if it affects IE 7 as I have not installed
that for testing lately. Note that even though the prefix of
"javascript:" is used, the setTimeout function assumes it's calling a
VBScript function, presumably because the first script block is a
VBScript block.

Here is a very simple page that shows this bug:
http://www.digitolle.net/news/testscriptbug.htm

and here is the source code:

--------

<html>
<head>
<title>Test Script Bug</title>
<!-- script type="text/javascript">
// If JavaScript is the first script, setTimeout works properly
// Unrem this script and both buttons will work.
</script -->
<script type="text/vbscript">
' Just because this VBScript block exists,
' setTimeout uses VBScript naming conventions.
' Therefore, double underscore functions will fail
' Rem this block out, and both buttons will work
' Note that calling the function directly always works.
</script>
</head>
<body>
<script type="text/javascript">
function __x() {
alert("test");
}
</script>
<input type="button" value="This will Work"
onclick="javascript:__x();" />
<br />
<input type="button" value="This will Fail"
onclick="javascript:setTimeout('__x()', 0);" />
</body>
</html>

--------

The obvious workaround is to always include a JavaScript block before
any VBScript blocks, even if it's just an empty block. If anyone else
comes up with the same results on this test, please let me know. Of
course if this is a known issue and I'm beating a dead horse, again,
please let me know because it's an odd issue to look up and it's
definitely a brain stumper if you don't know it exists.
 
S

Shadow Lynx

Peter said:
Sorry, I see you've done that. The piece I remember reading said that the
script engine is initialized by the empty script set. No workaround was
provided, that "is" the workaround.

Now my question is, how long has this bug been around and did they fix
it in IE 7 (which would make me assume that it's not ever going to be
fixed in IE 6). You'd think that with the whole ASPX push, it'd be a
more serious bug to get squashed.
 
D

Dave Massy [MSFT]

Hi Shadow,
This is not a bug but is by design. Once a particular script language is
declared it is used for the rest of the document.
http://msdn.microsoft.com/library/d...dhtml/reference/objects/script.asp?frame=true
If you wish to use JScript statements in the same document then you need to
be specific about the language after the VBScript declaration. You can do
this by setting the language on the element with teh event handler
http://msdn.microsoft.com/library/d...uthor/dhtml/reference/properties/language.asp

Thanks
-Dave
 
R

Randy Webb

Shadow Lynx said the following on 8/9/2006 11:35 AM:
Now my question is, how long has this bug been around and did they fix
it in IE 7

No, it didn't get "fixed".
 
M

Martin Honnen

Followup-to set to microsoft.public.scripting.jscript

Shadow Lynx wrote:

This is a bug in IE 6 and possibly earlier versions (I only have v6 to
play with.)

In IE setTimeout takes a third parameter to indicate the script
language, see
<http://msdn.microsoft.com/library/d...author/dhtml/reference/methods/settimeout.asp>
So I am not sure the IE developers regard the behavior you see as a bug.
There is a way with setTimeout to indicate a language other than the
default script language (which is decided by the first script element).

And another workaround in JavaScript is to simply pass in a function and
not a string see
<http://home.arcor.de/martin.honnen/javascript/2006/08/test2006080901.html>
 
D

Dave Anderson

Shadow said:
Now my question is, how long has this bug been around and did
they fix it in IE 7 (which would make me assume that it's not
ever going to be fixed in IE 6). You'd think that with the whole
ASPX push, it'd be a more serious bug to get squashed.

I'd hardly call it serious -- much less a bug. Pick a language and stick to
it. You don't demand that IE follow the strict box model for some elements
in a document and quirks mode for others, do you?

If there's any *bug* in the system you describe, it's the introduction of
VBScript to the client-side. If I were MS, I would be in no hurry to make my
aspx pages broken in a significant number of browsers.
 
W

Walter Zackery

: The obvious workaround is to always include a JavaScript block before
: any VBScript blocks, even if it's just an empty block. If anyone else
: comes up with the same results on this test, please let me know. Of
: course if this is a known issue and I'm beating a dead horse, again,
: please let me know because it's an odd issue to look up and it's
: definitely a brain stumper if you don't know it exists.
:

Another workaround is to leave the vbscript block in place (that may be a
neccessity for other reasons) but to wrap the setTimeout function call.

<input type="button" value="This will Fail"
onclick="javascript:setTimeout(function(){__x()}, 0);" />

You can also wrap the function name in brackets to make it acceptable to
VBScript.

<input type="button" value="This will Fail"
onclick="javascript:setTimeout('[__x]()', 0);" />

Or you can you call an external function that in turn calls the problem
function.

function x(){__x();}
<input type="button" value="This will Fail"
onclick="javascript:setTimeout('x()', 0);" />
 
S

Shadow Lynx

Dave said:
I'd hardly call it serious -- much less a bug. Pick a language and stick to
it. You don't demand that IE follow the strict box model for some elements
in a document and quirks mode for others, do you?

If there's any *bug* in the system you describe, it's the introduction of
VBScript to the client-side. If I were MS, I would be in no hurry to make my
aspx pages broken in a significant number of browsers.

I actually assumed that it was by design as far as IE was concerned.
The actual "bug" I am referring to is in reference to ASPX.
Specifically, auto-generated client-side code such as
"javascript:setTimeout('__doPostBack(\'anyASPXcontrol\',\'\')', 0)"
will break if a VBScript block is the first script block on the page.
This is, of course, out of my hands as it's an ASPX issue. Microsoft
would need to fix their statement so that the setTimeout function
specifies the JavaScript language.

Please note that Microsoft is not using VBScript for ASPX pages, but I
and others may choose to use VBScript code for various reasons, and if
we do, we can potentially "break" the vast majority of client-side code
generated by ASP.NET and the reason the code stops working isn't all
that obvious.
 
D

Dave Anderson

Shadow said:
...but I and others may choose to use VBScript code for
various reasons, and if we do, we can potentially "break"
the vast majority of client-side code generated by ASP.NET
and the reason the code stops working isn't all that
obvious.

In my opinion, [not using VBScript on the client] should have been an
obvious choice from the beginning. ASP.NET would have been a business
failure if it did not generate widely-compatible code, so Microsoft wisely
deferred to JScript.

You should thank them. They trumped your "various reasons" before you wrote
yourself deeper into a corner by writing for an ever-shrinking market share:
http://www.w3schools.com/browsers/browsers_stats.asp

For what it's worth, I have absolutely nothing against IE other than its
failure to correct implementation errors in areas it purports to have
conformance (document.getElementById() and Number.toFixed() come to mind). I
don't even CARE that it supports VBScript. I only care that nobody else
does, so I do not send VBScript to the client.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top