Flash calling window.location .hash causes IE6 crash

[Simula]

I am developing an HTML javascript application and I want to preserve
state in a way that can be book-marked. I chose HTML anchors as a means
of preserving state. When the application changes state, the HTML page
URL would change from default.html to default.html#st ateA.

example: http://pearstudios.com/javascript/lo...hAndFlash.html

This has worked perfectly within HTML and javascript alone, however,
when connecting Flash and javascript, this is the one sticking point.
Every other javascript function that I have called from Flash using
getURL("javascr ipt: x"); works perfectly, but when window.location .hash
= "x";, window.location .href = "baseUrl.ht ml#" + "x";, or
window.location .assign("baseUr l.html#" + "x"); is called from Flash, IE
6.0 crashes (or replaces the current page with a blank page). Oddly,
the crash occurs the second time Flash calls the javascript function.

Does anyone have any idea why this is happening and how I can get
around this problem?

Thanks,
Mark

[Richard Cornford]

Simula wrote:

I am developing an HTML javascript application and I want
to preserve state in a way that can be book-marked. I
chose HTML anchors as a means of preserving state. When
the application changes state, the HTML page URL would
change from default.html to default.html#st ateA.

example: http://pearstudios.com/javascript/lo...hAndFlash.html

This has worked perfectly within HTML and javascript
alone, however, when connecting Flash and javascript,
It appears that the only mechanism flash offers for executing javascript
(as opposed to its own ECMAScript implementation) is the use of the
javascript pseudo protocol and the getURL function.

The use of the javascript pseudo protocol is strongly discouraged where
it is not being used to replace page content because it is has harmful
consequences in numerous web browsers including Windows IE 6. Many web
developers carry on using javascript pseudo protocol hrefs and remain
unaware of the harmful consequences because they never see them.
However, the archives for this group provide many examples of those
consequences.

The javascript pseudo protocol is a mechanism for replacing a page's
contents with a string that results from the evaluation of a javascript
expression. When the expression used evaluates to an undefined value (as
most function calls would) the browser does not replace the contents of
the current page. However, the use of the javascript pseudo protocol
still looks to the browser like navigation. As a result some browsers
put the current page into a 'waiting' state, pending its expected
replacement.

In this state browsers stop doing some resource hungry tasks, such as
animating animated GIF images, and image swapping onmouseover. These are
the most visible manifestations of the altered state of the page
following the use of the javascript pseudo protocol, other less visible
consequences of the state change mean that once a javascript pseudo
protocol has been used all bets are off as to how the browser
environment will behave next.

That you feel able to characterise the behaviour of the browser
following javascript pseudo protocol use as 'worked perfectly' suggests
very good fortune or very superficial testing.
this is the one sticking point. Every other javascript
function that I have called from Flash using
getURL("javascr ipt: x"); works perfectly, but when
window.location .hash = "x";,
window.location .href = "baseUrl.ht ml#" + "x";,
These are expressions not function calls. If these expressions are
within the javascript pseudo protocol expression, and not the operand of
the - void - operator, their use might be dangerous, as expressions
result in values and replacing the mark-up of current document with the
result of such an expression is unlikely to produce a desirable outcome.
or window.location .assign("baseUr l.html#" + "x");
is called from Flash, IE 6.0 crashes (or replaces
the current page with a blank page). Oddly, the crash occurs the second time Flash calls
the javascript function.
If the effect is only observed on the second use of a javascript pseudo
protocol then it is very likely to be the consequence of the state
change in the page provoked by the initial use.
Does anyone have any idea why this is happening and how
I can get around this problem?

You should totally abandon the use of the javascript pseudo protocol,
but you cannot do so when your only means of calling javascript is
Flash's getURL method. So your only options are to re-think the state
preservation mechanism, or abandon using Flash as part of the
application.

Richard.

[VK]

Richard Cornford wrote:

Simula wrote:

I am developing an HTML javascript application and I want
to preserve state in a way that can be book-marked. I
chose HTML anchors as a means of preserving state. When
the application changes state, the HTML page URL would
change from default.html to default.html#st ateA.

example: http://pearstudios.com/javascript/lo...hAndFlash.html

This has worked perfectly within HTML and javascript
alone, however, when connecting Flash and javascript,

It appears that the only mechanism flash offers for executing javascript
(as opposed to its own ECMAScript implementation) is the use of the
javascript pseudo protocol and the getURL function.

The use of the javascript pseudo protocol is strongly discouraged where
it is not being used to replace page content because it is has harmful
consequences in numerous web browsers including Windows IE 6. Many web
developers carry on using javascript pseudo protocol hrefs and remain
unaware of the harmful consequences because they never see them.
However, the archives for this group provide many examples of those
consequences.

The javascript pseudo protocol is a mechanism for replacing a page's
contents with a string that results from the evaluation of a javascript
expression. When the expression used evaluates to an undefined value (as
most function calls would) the browser does not replace the contents of
the current page. However, the use of the javascript pseudo protocol
still looks to the browser like navigation. As a result some browsers
put the current page into a 'waiting' state, pending its expected
replacement.

In this state browsers stop doing some resource hungry tasks, such as
animating animated GIF images, and image swapping onmouseover. These are
the most visible manifestations of the altered state of the page
following the use of the javascript pseudo protocol, other less visible
consequences of the state change mean that once a javascript pseudo
protocol has been used all bets are off as to how the browser
environment will behave next.

That you feel able to characterise the behaviour of the browser
following javascript pseudo protocol use as 'worked perfectly' suggests
very good fortune or very superficial testing.

this is the one sticking point. Every other javascript
function that I have called from Flash using
getURL("javascr ipt: x"); works perfectly, but when
window.location .hash = "x";,
window.location .href = "baseUrl.ht ml#" + "x";,

These are expressions not function calls. If these expressions are
within the javascript pseudo protocol expression, and not the operand of
the - void - operator, their use might be dangerous, as expressions
result in values and replacing the mark-up of current document with the
result of such an expression is unlikely to produce a desirable outcome.

or window.location .assign("baseUr l.html#" + "x");
is called from Flash, IE 6.0 crashes (or replaces
the current page with a blank page).

Oddly, the crash occurs the second time Flash calls
the javascript function.

If the effect is only observed on the second use of a javascript pseudo
protocol then it is very likely to be the consequence of the state
change in the page provoked by the initial use.

Does anyone have any idea why this is happening and how
I can get around this problem?

You should totally abandon the use of the javascript pseudo protocol,
but you cannot do so when your only means of calling javascript is
Flash's getURL method. So your only options are to re-think the state
preservation mechanism, or abandon using Flash as part of the
application.

Richard.

To Richard:
Interesting, but abstract and useless: like a resonning "Why all people
should be brothers". javascript: pseudo-protocol is a God's gift for
communication between the page script and Flash/Java; because the
*official* communucation ways work only on paper and in damaged minds
of people who wrote these papers.

To OP:
to make javascript: call reliable, *ALWAYS* use void() wrapper.

In your Flash (on the old ActiveScript, the new one I did not learn):
....
Set jsCommand = "setCookie( " & cookieValue & ")";
Set jsCode = "javascript:voi d(" & jsCommand & ")";
getURL(jsCode);
....

P.S. If you want to keep a *state* of any kind, cookies should be
always the first choice.

P.P.S. IE traditionally has big problems with anchors even w/o any
script. Versions 3, 4 and 5 (in different minor releases) tended to
crach when you simply navigated from one anchot to another on the same
page.

[Simula]

I really appreciate the help Richard. I tried all sorts of things to
de-couple the location.hash from the Flash call (even changing global
variables that were polled by native javascript code). I couldn't make
sense of IE6's behavior, but your explanation of the 'waiting state'
makes everything clear.

There is another method of attempting Flash to javascript communication
- Flash FS commands. Do you know if FS commands cause any similar
browser problems?

Thank you so much for the detailed explanation,
Mark

[Richard Cornford]

VK wrote:

Richard Cornford wrote: <snip>

The use of the javascript pseudo protocol is strongly
discouraged where it is not being used to replace page
content because it is has harmful consequences in
numerous web browsers including Windows IE 6. <snip>

Oddly, the crash occurs the second time Flash calls
the javascript function.

To Richard:
Interesting, but abstract and useless: like a resonning
"Why all people should be brothers". javascript:
pseudo-protocol is a God's gift for communication between
the page script and Flash/Java; because the *official*
communucation ways work only on paper and in damaged minds
of people who wrote these papers.
Navigating to a javascript pseudo-protocol href that does not result in
the replacement of the current page is an act akin to kicking the
browser really hard. How well it will function after that act is
anyone's guess, beyond being certain that particular browsers will stop
performing particular actions.

You might think that kicking browsers is acceptable because you have
never been able to recognise the consequences as related to the action,
but that doesn't make it so. Indeed the fact that you perceive browser
scripting as buggy and chaotic well beyond what anyone else experiences
is likely, at least in part, the result of kicking browsers into states
in which they were not expecting to be scripted.
To OP:
to make javascript: call reliable, *ALWAYS* use
void() wrapper.
void - is an operator and should not be presented in a way that may give
the mistaken impression that it is a function.

If the expression evaluated in a javascript pseudo protocol href is a
function call that returns the Undefined value (as they all do if they
are not explicitly asked to return something else) then using that value
as the operand for the - void - operator will make no difference to the
outcome at all.

I realise that analysing cause and effect from observed behaviour is a
skill you don't posses, but the factor that needs explaining here is why
the effect is only observed on the _second_ use of the javascript
pseudo-protocol. In all circumstances where applying the - void -
operator to the evaluated result of an expression within a javascript
pseudo protocol href would make any difference to the outcome the effect
would be observed on each and every use of the href, including the
first.

<snip> P.S. If you want to keep a *state* of any kind, cookies
should be always the first choice.
For you that may be the case, for everybody else persistent cookies
would be the last choice of mechanism for maintaining state.
P.P.S. IE traditionally has big problems with anchors even
w/o any script. Versions 3, 4 and 5 (in different minor
releases) tended to crach when you simply navigated from
one anchot to another on the same page.

I don't know about IE 3 (and don't care much at this point) but for IE 4
& 5 that is pure BS. Once again, with your catastrophicall y bad
scripting you may encounter this effect, but when your are encountering
problems that nobody else experiences it makes more sense to look at
what your are doing wrong rather than blaming the browser when it
suffers from it.

Richard.

[Richard Cornford]

Simula wrote:

I really appreciate the help Richard. I tried all sorts of
things to de-couple the location.hash from the Flash call
(even changing global variables that were polled by native
javascript code). I couldn't make sense of IE6's behavior,
but your explanation of the 'waiting state' makes everything
clear.

There is another method of attempting Flash to javascript
communication - Flash FS commands. Do you know if FS
commands cause any similar browser problems?

Ah, yes, I remember FS commands. I have never used them, but then it has
been more than 3 years since I have had anything to do with Flash, as I
do cross-browser work. As I understand it the potential problem with
them are that they require the browser to fully and correctly implement
a standardised interface for plug-ins, and the browsers just don't. At
least not all of them, which may or may not be a problem depending on
how controllable/restricted the target browsers for your application are
(and what those actual browser do).

Richard.

[VK]

Richard Cornford wrote:

The use of the javascript pseudo protocol is strongly
discouraged where it is not being used to replace page
content because it is has harmful consequences in
numerous web browsers including Windows IE 6.

void() was specially introduced both in NN3 and IE3 when the need in
script-launching links got really bad.
Don't forget (if you had a chance ever learn it of course) that at that
time there was not any Event object you could capture, cancelBubble
etc.

So the scripters had to use the "empty anchor" trick:
<a href="#" onClick="myFunc tion()">Click here</a>

Unfortunatelly in IE3 the empty anchor was set as a synonym of the top
of the document. So clicking such pseudo-link caused the scroll on the
very top. Obviously for large documents it was not acceptable.

Then one tried the evident trick with "self-pointing anchor":
<a name="bogus" href="#bogus" onClick="myFunc tion()">Click here</a>
The results appeared to be disactrous on both rivals.

Both producers saw the problem and rushed to intriduce
javascript:void (0) construct, which solved the problem:
<a href="javascrip t:void(0)" onClick="myFunc tion()">Click here</a>

Thusly void() (actually void(0) ) was made exclusively for javascript
pseudo-protocol and overall it doesn't have any other reasonnable use.
So *javascript:voi d(anything)* is totally correct and
producer-predicted construction. It has no more chance to "kick off"
the browser than <body> or <html> tags.

It is a totally other story that since 4th versions users have other
means to create and handle pseudo-links.

<snip a lot of foo>
I don't know about IE 3 (and don't care much at this point) but for IE 4
& 5 that is pure BS.

I publich here the minor versions/OS of IE with the "anchor
instability" (skipping IE3), and you post in this group a message with
the string "Intenet Explorer is the best browser!" repeated 10 times.
If I fail, my post will repeat "I am an ignorant fool" 10 times. We
shall make it "no cache" of course.
???
Interestingly enough the "anchor instability" was always acted starting
the second and more navigation within the same page, but never on the
first one.

[Martin Honnen]

Simula wrote:

This has worked perfectly within HTML and javascript alone, however,
when connecting Flash and javascript, this is the one sticking point.
Every other javascript function that I have called from Flash using
getURL("javascr ipt: x"); works perfectly, but when window.location .hash
= "x";, window.location .href = "baseUrl.ht ml#" + "x";, or
window.location .assign("baseUr l.html#" + "x"); is called from Flash, IE
6.0 crashes (or replaces the current page with a blank page).

But if you use getURL why do you need to couple it with script and
window.location .hash?
Doesn't it suffice if you simply call
getURL('#anchor Name')
in Flash?

--

Martin Honnen
http://JavaScript.FAQTs.com/

[VK]

Simula wrote:

There is another method of attempting Flash to javascript communication
- Flash FS commands.

FS is broken (and always was). Don't waste your time on it. You you
may... for sport...

javascript:void (jsFunction) works stable and on all browsers.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>> The use of the javascript pseudo protocol is strongly
>> discouraged where it is not being used to replace page
>> content because it is has harmful consequences in
>> numerous web browsers including Windows IE 6.
void() was specially introduced both in NN3 and IE3 when the
need in script-launching links got really bad.
Do you have any evidence that this was the motivation behind the
introduction of the void operator in JavaScript 1.1, or are you making
this up off the top of your head again?
Don't forget (if you had a chance ever learn it of course)
that at that time there was not any Event object you
could capture, cancelBubble etc.
Not having an event object is not a barrier to cancelling most intrinsic
events in JavaScritp 1.1+.
So the scripters had to use the "empty anchor" trick:
<a href="#" onClick="myFunc tion()">Click here</a>
But people who understood what they were doing had the option of
cancelling the navigation in the onclick event from JavaScript 1.1
onwards, so manifestations of the common practice of writing scripts
without understanding what you are doing have no significance.
Unfortunatelly in IE3 the empty anchor was set as a
synonym of the top of the document.
The # character as a URI is an empty URI followed by an empty fragment
identifier. RFC 2396, section 4.2, defines that as a reference to the
"start of the document". The only decision on the subject that the
browser manufactures have made is to equate the "start" of a document
with the top of a displayed page. Not an unreasonable interpretation at
all.
So clicking such pseudo-link caused the scroll on the
very top.
It is not a pseudo-link, it is a link with a well formed URI that refers
to the "start of the document". Navigating to the top of the page is the
navigation such a URI is requesting.
Obviously for large documents it was not acceptable.
If you want to go to the top of the current page that is completely
acceptable.
Then one tried the evident trick with "self-pointing
anchor":
<a name="bogus" href="#bogus" onClick="myFunc tion()">
Click here</a>
The results appeared to be disactrous on both rivals.

Both producers saw the problem and rushed to intriduce
javascript:void (0) construct, which solved the problem:
<a href="javascrip t:void(0)" onClick="myFunc tion()">
Click here</a>
They introduced the - void - operator at exactly the point that they
made intrinsic events cancellable, so there is no reason to believe that
the introduction of - void - was in any way related.
Thusly void() (actually void(0) ) was made exclusively
for javascript pseudo-protocol and overall it doesn't
have any other reasonnable use.
Which would explain why you don't find any - void - operators in any
languages that cannot be executed in pseudo-protocol hrefs?
So *javascript:voi d(anything)* is totally correct and
producer-predicted construction. It has no more chance
to "kick off" the browser than <body> or <html> tags.
Reality is not altered by your unwillingness to recognise it.
It is a totally other story that since 4th versions users
have other means to create and handle pseudo-links.

<snip a lot of foo>
That is right; never wonder why people disagree with you, just ignore
whatever they have to say.
I don't know about IE 3 (and don't care much at this
point) but for IE 4 & 5 that is pure BS.

I publich here the minor versions/OS of IE with the "anchor
instability" (skipping IE3), and you post in this group a
message with the string "Intenet Explorer is the best
browser!" repeated 10 times. If I fail, my post will repeat
"I am an ignorant fool" 10 times. We shall make it "no
cache" of course. ???

Incoherent as ever.
Interestingly enough the "anchor instability" was always
acted starting the second and more navigation within the
same page, but never on the first one.

It remains no surprise to me that your particular style of scripting
provokes problems with web browsers that have apparently never been seen
by anyone else. But as you never seem to understand what you are doing
there is no point pursuing the real cause and effect relationships
involved with you.

Richard.