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#stateA.

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("javascript: x"); works perfectly, but when window.location.hash
= "x";, window.location.href = "baseUrl.html#" + "x";, or
window.location.assign("baseUrl.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#stateA.

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("javascript: x"); works perfectly, but when
window.location.hash = "x";,
window.location.href = "baseUrl.html#" + "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("baseUrl.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#stateA.

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("javascript: x"); works perfectly, but when
window.location.hash = "x";,
window.location.href = "baseUrl.html#" + "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("baseUrl.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:void(" & 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 catastrophically 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="myFunction()">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="myFunction()">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="javascript:void(0)" onClick="myFunction()">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:void(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("javascript: x"); works perfectly, but when window.location.hash
= "x";, window.location.href = "baseUrl.html#" + "x";, or
window.location.assign("baseUrl.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('#anchorName')
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="myFunction()">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="myFunction()">
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="javascript:void(0)" onClick="myFunction()">
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:void(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.

[VK]

Richard Cornford wrote:

VK wrote:

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?

Yes, because I was one of these who wrote complains to NN/IE support
and who got the "congratulations, this problem is solved now this way"
letter.

Not having an event object is not a barrier to cancelling most intrinsic
events in JavaScritp 1.1+.
Not cancelling but calling JS functions from links.
But people who understood what they were doing had the option of
cancelling the navigation in the onclick event from JavaScript 1.1
onwards.
Yes, and since 4th versions javascript:void(0) started to obsolete
(despite it is still more code effective then
stopPropagation/returnValue mess).
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".
Yes, because IE did it, and they got the side of the winner. I *hate*
these boll-less eggheads. Ever since the CSS1 proposal they did
*nothing* creative but just taking the side of the up-to-the-moment
winner and writing standards out of it.
That is right; never wonder why people disagree with you, just ignore
whatever they have to say.

That's right, and the only right judge here would be the OP. If poor
Simura overcomes the fear to be banned forever from this group or
teared apart by The Gung, he will say that javascript:void(jsCode)
works stable, universally and as intended.

Is it, Simura? Don't be affraid, I'll cover you.

[Richard Cornford]

VK wrote:

Richard Cornford wrote: <snip>

Not having an event object is not a barrier to cancelling
most intrinsic events in JavaScritp 1.1+.

Not cancelling but calling JS functions from links.

Intrinsic events became cancellable in Netscape 3/JavaScritp 1.1,
rendering most javascript pseudo-protocol hrefs redundant (at least once
earlier browsers had expired, so a long time in the past now).

But people who understood what they were doing had the
option of cancelling the navigation in the onclick event
from JavaScript 1.1 onwards.

Yes, and since 4th versions javascript:void(0) started to
obsolete (despite it is still more code effective then
stopPropagation/returnValue mess).

You have made it obvious in the past that intrinsic event handlers are
another area where you struggle to comprehend what is actually
happening. That leaves you no judge of how to code them efficiently.

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

Yes, because IE did it, and they got the side of the winner.
I *hate* these boll-less eggheads. Ever since the CSS1
proposal they did *nothing* creative but just taking the
side of the up-to-the-moment winner and writing standards
out of it.

IE 3 was not an "up-to-the-moment winner", it was a minority browser
that struggled against Netscape's competition.

That is right; never wonder why people disagree with you,
just ignore whatever they have to say.

That's right, and the only right judge here would be the
OP. If poor Simura overcomes the fear to be banned forever
from this group or teared apart by The Gung, he will say
that javascript:void(jsCode) works stable, universally and
as intended.

If you had any comprehension of logic, and understanding of the actions
of the - void - operator, you would see that my explanation of why its
use cannot make any difference in this case must be true (that was the
explanation you dismissed as "foo"). Your preference for believing
that - void - is some sort of magical panacea is precisely the sort of
thinking that puts you in a minority of one and gives you the impression
that everyone else represents a gang for calling you the fool you so
self evidently are.

If the problem with the OP's javascript pseudo protocol use was
non-Undefined results of evaluation the expression the symptoms would be
apparent at the _first_ invocation, not the second.
Is it, Simura? Don't be affraid, I'll cover you.

Yes, why not try it. It won't make a jot of difference, just waste a bit
of time finding that out.

Richard.

[Simula]

Hello Everyone,

I didn't want to reply until I had done more thorough testing. It
turns out that testing confirms Richard's understanding of IE6's
behavior. When Flash interacts with javascript in its parent document
via getURL, it does indeed degrade IE6's normal operation. If native
javascript itself then attempts to modify the page's hash, the error is
reproduced.

VK, even this statement resulted in the ensuing sub-optimal IE6
behavior: getURL("javascript:void(alert('hello world'))");

I am still testing to determine if modifying the page directly with
getURL("#stateValue"); will work at all. It does not work in Flash MX,
I will test MX 2004 tomorrow.

Lastly, I am considering the use of an Iframe that will contain a
separate document housing the flash movie. I am hoping that the damage
that flash's getURL does to browser operation will be limited to that
iframe, but I have yet to test. Depending on those results I will look
back into FScommands.

Thanks everyone for your help, I greatly appreciate it,
Mark

[VK]

Simula wrote:

I didn't want to reply until I had done more thorough testing. It
turns out that testing confirms Richard's understanding of IE6's
behavior. When Flash interacts with javascript in its parent document
via getURL, it does indeed degrade IE6's normal operation. If native
javascript itself then attempts to modify the page's hash, the error is
reproduced.
VK, even this statement resulted in the ensuing sub-optimal IE6
behavior: getURL("javascript:void(alert(*'hello world'))");

First of all, leave the slang like "sub-optimal browser behavior" for
the board of directors, if you ever have to explain why the project has
to be delayed for a month or two :-) :-|

Secondly, all this "black is white" crap got me so deep (I'm still
coming back from the Array story) that I specially went into my oldest
archives.

1) Go to <http://www.geocities.com/schools_ring/FlashDemo.zip>
(enclosed .fla source)
Here is the working flash demo using javascript:void() to call
JavaScript functions. It's a primitive test counter, each second it
displays the Timer variable value kept in Flash.
Both you and Mr. Conford can launch it in IE6 (IE5, IE4) and click
Start/Stop buttons waiting how it will "kick off" the browser. Just
don't forget a take a Tolstoy book for this spare time.

1-a) It appeared that in IE6 they narrowed the security: getUrl must be
literal, so you cannot pass variable directly. You have to use
FlashMovie.GetVariable() method.

1-b) The old good FlashMovie.GetVariable() method existing since NN4.0
is broken on FF and Opera, so you need to look for a side walk which
I'm not up to (VML/SVG is the future anyway).
To finish with javascript:void() expression: I'm referring you to
"Client-Side JavaScript Guide" (c) 1999 Netscape Corporation:
<QUOTE START>
void
The void operator is used in either of the following ways:

1. void (expression)2. void expression
The void operator specifies an expression to be evaluated without
returning a value. expression is a JavaScript expression to evaluate.
The parentheses surrounding the expression are optional, but it is good
style to use them.

You can use the void operator to specify an expression as a hypertext
link. The expression is evaluated but is not loaded in place of the
current document.

The following code creates a hypertext link that does nothing when the
user clicks it. When the user clicks the link, void(0) evaluates to 0,
but that has no effect in JavaScript.

<A HREF="javascript:void(0)">Click here to do nothing</A>
The following code creates a hypertext link that submits a form when
the user clicks it.

<A HREF="javascript:void(document.form.submit())">Cli ck here to
submit</A>
<END OF QUOTE>

But of course "stupid Netscape engineers" simply did not know what the
hey are they talking about. God thanks we have people like Mr.Cornford
to get the picture clear.

To finish with OP's problem:
Simula, whatever you're doing, you're doing something very wrong and
weird. As Mr.Honnen had pointed, you didn't need any javascript:
pseudo-protocol to simply navigate to an *existing* anchor. So I guess
you're patching the page URL with non-existing anchors. It simply will
not work anyhow long, as well as changing say [search] part of the URL.
URL is not a simple property. Each URL change means *new server
request*.
So whatever bad experience you might have with cookies before, it's now
the time to overpass the old trauma and start using the conventional
way.

[markTurney]

VK,

I used your example to illustrate my testing. I have inserted two
anchors at the top of the page, at the bottom of the page are two
buttons that call a javascript function that changes the URL hash (I
did not modify the Flash movie at all).

http://pearstudios.com/pearstudios/j...FlashDemo.html

To reproduce the error, first click the first HTML button below the
flash movie, then click the Flash movie start button, then click on
both of the HTML buttons. At this point you will notice that the
functions called by the HTML buttons do not complete their expected
behavior. Then press either of the Flash movie buttons and the page
will turn white and become wholy unresponsive.

I have also modified the original example with a second Flash movie (to
the right of the previous Flash movie in my example) which shows Flash
calling getURL to navigate to existing page anchors, but failing.

http://pearstudios.com/pearstudios/j...hAndFlash.html

I am also pretty sure that the server is not contacted when an anchor
link is clicked, or the hash URL is otherwise modified. This is
inner-page navigation and should not concern the server at all. I do
know for a fact that all major browsers do not re-load a page when
javascript updates the hash of an URL.

In my case it is necessary to track state via URI because each change
in state corresponds to content that can be book-marked. Book marking
along with preserving the functionality of the forward and back buttons
are very important for the project.

If I am truly doing something very wrong, I would really appreciate you
digging into my code and pointing out the error of my ways. I am
always hoping to perfect my methods.

Thanks for all the help,
Mark

[markTurney]

VK,

I used your example to illustrate my testing. I have inserted two
anchors at the top of the page, at the bottom of the page are two
buttons that call a javascript function that changes the URL hash (I
did not modify the Flash movie at all).

http://pearstudios.com/pearstudios/j...FlashDemo.html

To reproduce the error, first click the first HTML button below the
flash movie, then click the Flash movie start button, then click on
both of the HTML buttons. At this point you will notice that the
functions called by the HTML buttons do not complete their expected
behavior. Then press either of the Flash movie buttons and the page
will turn white and become wholy unresponsive.

I have also modified the original example with a second Flash movie (to
the right of the previous Flash movie in my example) which shows Flash
calling getURL to navigate to existing page anchors, but failing.

http://pearstudios.com/pearstudios/j...hAndFlash.html

I am also pretty sure that the server is not contacted when an anchor
link is clicked, or the hash URL is otherwise modified. This is
inner-page navigation and should not concern the server at all. I do
know for a fact that all major browsers do not re-load a page when
javascript updates the hash of an URL.

In my case it is necessary to track state via URI because each change
in state corresponds to content that can be book-marked. Book marking
along with preserving the functionality of the forward and back buttons
are very important for the project.

If I am truly doing something very wrong, I would really appreciate you
digging into my code and pointing out the error of my ways. I am
always hoping to perfect my methods.

Thanks for all the help,
Mark

[VK]

> If I am truly doing something very wrong, I would really appreciate you

digging into my code and pointing out the error of my ways. I am
always hoping to perfect my methods.

Thanks for all the help,
Mark

You're doing nothing really terrible :-)
Yes, using anchors as cookies is a bit strange, but you're the king.
The problem is that you're trying to use something that is broken: IE
anchors scripting. And javascript:void(expression) has nothing to do
with that. Just to start with, you may visit this page:
<http://www.isaacschlueter.com/tests/anchors.html>
My strong sensation is that you can "kick off" IE by just using
JavaScript and anchors (no Flash or javascript:void() are needed).

If you give us some more details about your project structure,
something *working* will be definitely found in IE.

And about flashObject.GetVariable() method: indeed Flash plugin gets
broken if installed automatically on both FF and Opera:
<https://bugzilla.mozilla.org/show_bug.cgi?id=284057>
and they seem do not have any intention to fix it any soon.
To have a scriptable flash, you need to download the plugin right from
the Macromedia site and install it manually.

[Kevin Newman]

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?

Thank you so much for the detailed explanation,
Mark

FSCommand is problematic on a wide variety of browsers and platforms -
fortunately IE (3 through 7b) for 32-bit windows is not one of the
problematic ones! It always works, it's just a pain to set up because
you have to use a VBScript function to capture the FSCommand and then
route it to a JavaScript call.

Since your problem is only related to IE, I would suggest that you use
FSCommand in IE, and stick with the getURL method for the others.

You could also take a look at Macromedia's Flash / JavaScript
Integration Kit (FJIK) though they have an advertising clause in their
license to consider. This uses the getURL method though, so I'm not sure
it will help you out.

http://weblogs.macromedia.com/flashjavascript/
http://www.osflash.org/doku.php?id=flashjs
Also, I have actually been working on a couple of scripts that are
designed to deal with your specific issue :-) It used to be one big
messy script, but I've recently reworked it from scratch and come up
with something manageable, if a bit rough around the edges.

http://www.unfocus.com/Projects/HistoryKeeper/
http://www.unfocus.com/Projects/FlashSuite/

unFocus History Keeper is the part that generates the history and sets
the hash for bookmarking/url sharing. I consider this beta software at
this point.

unFocus Flash Suite is much less complete, and will consist of a setup
script that will output the appropriate html and setup the
wrapper/emulator for Flash Scripting, and FSCommand, as well as the
History Keeper, and a flash detector (complete). And if I can find the
time I will add a serializer and functionality similar to what FJIK
provides.

If you are interested in these, I would absolutely love to get some
feedback on the interface and implementation of these scripts, since I'd
like them to be as robust and usable as possible.

One last note - I was unable to get the History Keeper and FJIK to play
nicely together (I think it has to do with the stuff that Richard
Cornford was talking about I bet).

Kevin N.

un**********@unFocus.com

[Corvus]

Simula/Mark,

You have my sympathies. I found this discussion while trying to shed some light on an almost identical problem involving QuickTime. QT is even more restricted than Flash in terms of options for interacting with browser JavaScript, as it doesn't offer the FSCommand alternative. Until this discussion, I'd never come across anyone denigrating the use of the javascript: pseudo-protocol as a means of passing JavaScript commands to a browser. Apple, indeed, specifically recommends its use for the purposes of calling JavaScript from QT:

http://developer.apple.com/documenta...sFromQuickTime

I'm well aware of the inadvisability of using javascript: as the HREF of a link on accessibility grounds, and I never use it in web sites except occasionally for links that are written in with document.write() in the first place (even then, an onClick handler is probably preferable). Like you, I can claim, based on extensive testing, that in such uses I have found it to work entirely as expected.

The issue in Windows Internet Explorer is very specific, and clearly points to a bug somewhere in the linkages between the ActiveX controls and the browser JavaScript implementation. Whether that bug is a similar one that exists in both the QT and SWF plugins, or it's inherent to the Microsoft ActiveX architecture, I cannot speculate, though Occam's razor would suggest that the latter is more likely.

Here's my situation:

A web page contains a number of <div>s that, if the visitor's browser has JavaScript and cookies enabled, are hidden from view. One only is visible, giving introductory text for the page. By controlling a QT panorama and mousing over hotspots, JavaScript commands are sent to the browser to hide the currently visible <div> and show another. As I've already indicated, these commands can only be sent to the browser from QT via the javascript: pseudo-protocol.

This much has worked entirely as expected in extensive testing across browsers and platforms (bar NN4, but that's another story).

If the viewer wishes, they can reveal all the text in the <div>s by clicking a link that reloads the page, subsituting a different style sheet that makes all the <div>s visible. This choice is stored in a cookie so that other similarly-constructed pages on the same site will appear in the preferred way.

When this choice has been made, mousing over the hotspots on the QT panorama does nothing. However, clicking on the hotspot will call the same javascript: command with a different parameter, causing the browser to jump to an anchor tag at the start of the relevant <div> of text (the same <div> that would have been revealed in the mouse-over state).

Again, this works as expected, except in Windows IE:
The first time a hotspot is clicked, it works as expected, and the relevant hash is added to the end of the URL in the address bar.
Return to the panorama and click another hotspot, and again the browser jumps to the relevant item of text, but the URL in the address bar does not update.
Return to the panorama and click a hotspot again, and the browser window goes blank, with the 'back' button non-functional.

While this does suggest that the javascript: pseudo-protocol may have left the browser in an undefined state, the real clincher is that the problem does not occur if the same javascript: function is called from <a> tags. In such a case, one can continue to jump from anchor tag to anchor tag ad-infinitum. This, combined with your experiences in Flash, clearly points to a bug somewhere in the plug-ins or the ActiveX system. What's particularly strange, given the comments in this discussion, is that problems only seem to manifest themselves when the javascript: call is used for precisely the purpose intended - to change the current URL. The fact that the second click of a hotspot in my scenario above leaves the address bar displaying a URL that's different from the one currently being viewed is clearly yet another security flaw in IE. (It's worth noting, by the way, that calling an alert() of the location.href string at this point gives the correct result, so the browser does know where it's navigated to, it's just that it hasn't updated the address bar to reflect the fact).

I'm afraid I can't offer a solution. I have tried every conceivable combination of JavaScript commands, from checking for the presence of a # symbol in the current HREF and replacing the part after it, to window.navigate(), document.URL, window.location.hash and everything in between. Nothing makes a difference.

It would appear that until Apple and Macromedia/Adobe offer alternative means of calling JavaScript from media presented with their plug-ins, and/or Microsoft fixes the apparent bug, this is one area of DHTML/multimedia integration that will have to remain off-limits, which is a shame for everyone.