Nasty Firefox problem with history.back()

[Heinrich Wolf]

Hi all

I have a history.back() problem with FF(2). IE works as expected, while FF
does not. The multi frame website setup as a whole with a lot of frame
content switching works flawlessly in both browsers. In one situation and
frame I have a long scrollable list of cars offered for sale. Some list
lines are linked to a separate page with images, to be loaded into the
same frame as the listing.

On closing this image page with <a href="javascript:history.back();">
Button.gif</a>, the listing reappears, maintaining the former vertical
position and showing the corresponding line in the same place where the
visitor started from (as opposed to the listing reverting to the top).
This appears to the visitor as a sleek operation and I think is essential.

Now, some cars have 2 or more images, implemented as rollover with <a
href="#" onClick= "change();">Close.gif</a- and with this, the problem
starts.

This are the two involved functions:

var b1, b2, b3
function LoadImages() { // onLoad
b2 = new Image(); b2.src = "image_2.jpg";
b3 = new Image(); b3.src = "image_3.jpg";
b1 = new Image(); b1.src = "image_1.jpg";
}
var n = 3
var i = 1
function change() {
i = i + 1;
if (i == (n+1)) i = 1;
img = "b" + i + ".src";
document.placeholder.src = eval(img); return false
}

In IE, this works consistently with one only or more images. In FF
however, the return history.back() shows a peculiar attitude. With single
image pages or multi image pages - but without actuating the rollover - FF
returns as expected with a single click. But after actuating the rollover,
FF requires a double click. As this is inconsistent and wholly unexpected,
it appears to the visitor as a bug and as "does not work properly".

For days I trial-and-errored a work-around, but to no avail, even with
separate code using navigator.appName. It has nothing to do with focus, as
moving focus around with (Shift)/Tab has no influence. My code appears to
me as straight forward and without any apparent interference between
change and close. The peculiar FF behaviour applies even to the original
back button of FF itself. So it looks like some kind of "lock in the FF
engine" - if possible at all.

I don't mind supplying more code and url, if you find it useful. But for
now I would like to ask for a first opinion - and probably even snag and
work-around are known to professionals (which I'm not).

Very many thanks for your consideration and possible help.
Heinrich Wolf

[Kristin Bruun]

On Mon, 28 May 2007 19:21:23 +0200, Heinrich Wolf
<XX************@hispeed.chwrote:

Hi all

I have a history.back() problem with FF(2). IE works as expected, while
FF does not. The multi frame website setup as a whole with a lot of
frame content switching works flawlessly in both browsers. In one
situation and frame I have a long scrollable list of cars offered for
sale. Some list lines are linked to a separate page with images, to be
loaded into the same frame as the listing.

On closing this image page with <a href="javascript:history.back();"
Button.gif</a>, the listing reappears, maintaining the former vertical
position and showing the corresponding line in the same place where the
visitor started from (as opposed to the listing reverting to the top).
This appears to the visitor as a sleek operation and I think is
essential.

Now, some cars have 2 or more images, implemented as rollover with <a
href="#" onClick= "change();">Close.gif</a- and with this, the problem
starts.

This are the two involved functions:

var b1, b2, b3
function LoadImages() { // onLoad
b2 = new Image(); b2.src = "image_2.jpg";
b3 = new Image(); b3.src = "image_3.jpg";
b1 = new Image(); b1.src = "image_1.jpg";
}
var n = 3
var i = 1
function change() {
i = i + 1;
if (i == (n+1)) i = 1;
img = "b" + i + ".src";
document.placeholder.src = eval(img); return false
}

In IE, this works consistently with one only or more images. In FF
however, the return history.back() shows a peculiar attitude. With
single image pages or multi image pages - but without actuating the
rollover - FF returns as expected with a single click. But after
actuating the rollover, FF requires a double click. As this is
inconsistent and wholly unexpected, it appears to the visitor as a bug
and as "does not work properly".

For days I trial-and-errored a work-around, but to no avail, even with
separate code using navigator.appName. It has nothing to do with focus,
as moving focus around with (Shift)/Tab has no influence. My code
appears to me as straight forward and without any apparent interference
between change and close. The peculiar FF behaviour applies even to the
original back button of FF itself. So it looks like some kind of "lock
in the FF engine" - if possible at all.

I don't mind supplying more code and url, if you find it useful. But for
now I would like to ask for a first opinion - and probably even snag and
work-around are known to professionals (which I'm not).

Very many thanks for your consideration and possible help.
Heinrich Wolf

I think you problem is best solved with history.go(-1);

--
There are 10 kinds of people:
those who know binary, and the others ...

[Heinrich Wolf]

Kristin Bruun wrote:

On Mon, 28 May 2007 19:21:23 +0200, Heinrich Wolf
<XX************@hispeed.chwrote:

>I have a history.back() problem with FF(2).

[skipped]

I think your problem is best solved with history.go(-1);

Unfortunately not, it behaves the same as history:back(). Actually, it
appears not as a Javascript issue, but Firefox. As mentioned before, the
"lock" applies even to the back button of Firefox itself and is entirely
independent of the history coding - if anything is realated to the
rollover code supplied.

But this rollover code appears as most straight forward, works well and to
me provides absolutely no hint about any flaws??

Might be appropriate to post in FF forums, but since it shows as a clear
non-performance of Javascript, I thought the issue might be known to Js
people and therefore chose to post here.

Any more ideas?
Thanks - HW

[news]

On May 28, 6:21 pm, Heinrich Wolf <[e-mail]:

On closing this image page with
<a href="javascript:history.back();">
Button.gif</a>

Now, some cars have 2 or more images,
implemented as rollover with <a
href="#" onClick= "change();">Close.gif</a-
and with this, the problem
starts.

With single image pages or multi image pages
- but without actuating the rollover - FF
returns as expected with a single click.
But after actuating the rollover,
FF requires a double click.

Of course it does - clicking your close.gif
causes the browser to call change(); and then
navigate to an un-named anchor in the same
page, because you've got href="#" in there.

So you need two back's to go back to the right
page in the history.

Rewrite the way you call your javascript and
all will be well. Either attach the call
directly to the onclick of the images, or
use this quick hack version:

<a href="#" onClick= "change();return false;">Close.gif</a>

[Yes there are _better_ ways of doing this, but
this solves his immediate problem].

That your page is ONLY usable to those with
javascript, but no doubt you will encounter
THAT little problem later...

[Heinrich Wolf]

ne**@chthonic.f9.co.uk schrieb:

On May 28, 6:21 pm, Heinrich Wolf <[e-mail]:

>On closing this image page with
<a href="javascript:history.back();">Button.gif</a>

>Now, some cars have 2 or more images,
implemented as rollover with
<a href="#" onClick= "change();">Close.gif</a-
and with this, the problem starts.

With single image pages or multi image pages
- but without actuating the rollover - FF
returns as expected with a single click.
But after actuating the rollover,
FF requires a double click.

Very many thanks for your helpful answer.
It gives me a lot to chew on...
Please allow some questions - not to question your
statements, but to get a clearer picture, if possible.

Of course it does - clicking your close.gif
causes the browser to call change(); and then
navigate to an un-named anchor in the same
page, because you've got href="#" in there.

So you need two back's to go back to the right
page in the history.

Rewrite the way you call your javascript and
all will be well. Either attach the call
directly to the onclick of the images, or
use this quick hack version:

<a href="#" onClick= "change();return false;">Close.gif</a>

I think I understand what you say, but why does the
"return false" at the end of function change() not
serve the same purpose?

[Yes there are _better_ ways of doing this, but
this solves his immediate problem].

Yes it does, and I'm most grateful for this.

I too tried to put the onClick into the image line:
<img onClick="change();return false;" name="placeholder" src="...
and it works well too - as you say.

Would you mind commenting any further on "better ways"?

That your page is ONLY usable to those with
javascript, but no doubt you will encounter
THAT little problem later...

I tested my project (only now) with js switched off and the
only real problem are the many rollovers. Would you please
indicate how to modify my js code?

I read somewhere to put an url in place of the # in
<a href="#" onClick="change();return false;">
Would that mean to load a complete new page for
each successive image? Would that be the proper way
to simulate a rollover without js?
One final question: would you know a recent book
on issues involved here? I know of www.w3.org and
google for js - but as usual, try to find the needle
in the haystack of statements. What would be helpful
is a clever book to set a frame of today's js use.
Very many thanks again!
Heinrich Wolf