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/locationHashAndFlash.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]

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/locationHashAndFlash.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]

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.


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.



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.


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]

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.

 

[Richard Cornford]

Richard Cornford wrote:

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.

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.

 

[VK]

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.

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?

 

[VK]

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]

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 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]

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]

Richard Cornford wrote:

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

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.

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'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]

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())">Click 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/javascript/counterExample/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/javascript/locationHashAndFlash.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/javascript/counterExample/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/javascript/locationHashAndFlash.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]

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.

(e-mail address removed)