Closed Bug 75139 Opened 23 years ago Closed 23 years ago

window.history.go(-1) does not work properly after a shift-reload

Categories

(Core :: DOM: Navigation, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 68847
mozilla0.9.1

People

(Reporter: slava, Assigned: radha)

References

()

Details

(Keywords: regression, testcase)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i686; en-US; 0.8.1) Gecko/20010327
BuildID:    2001032716

Construction window.history.go(-1) don't work. It sometimes work at first use.
But only once. After press at button, witch use this construction java script
generate error. 

Reproducible: Always
Steps to Reproduce:
1.go to www.amberda.i85.net
2.select Business from the left menu
3.Select ???????? from the Up menu (5th menu position from the left in up menu).
4.Go to the bottom of the page.
5. Click button <<?????<< at the page buttom
6. Button don't work and we have error in java script console


Actual Results:  Java Script construction window.history.go(-1) generate error:
Error: uncaught exception: [Exception... "Failure"  code: "-2147467259"
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"]

Expected Results:  Should go back in the frame there this command use. In
Netscape 4.* and Explorer this construction work.

 <form>
<input type='button' value='&lt;&lt;?????&lt;&lt;' onClick=window.history.go(-1)>
</form>

This construction generate error in java script console:

Error: uncaught exception: [Exception... "Failure"  code: "-2147467259"
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"]
I check this construction without frames - all work Ok. This error apear only
then page have many frames and we try to go back with this construction in
frame. History list corrypted then frame used ?
I was try to build frameset in frameset - similar to used in www.amberda.i85.net
- but in plain examples window.history.go(-1) work OK. But at real pages it
don't work. I dont understand why :(  In Netscape 4.* and MS Explorer 5.* all
work ok in www.amberda.i85.net :(
Yes !!! I reproduce this bug at the simple example. This example in english you
can find at http://www.amber-da.com.ua/Mozilla_bugs/history.go
not JS engine.  Over to session history....
Assignee: rogerl → radha
Component: Javascript Engine → History: Session
Keywords: testcase
QA Contact: pschwartau → claudius
Hmmm, this is a dupe of several bugs, but the one at the end of the chain is marked
VERIFIED Fixed, so maybe we have a regression on or hands? Bug 37055 is the relevant,
which is eventually a dupe of 18321
It was fixed ? But it exist :( And as i see - it's not my hand. I writing simple
example for duplicating this bug
(http://www.amber-da.com.ua/Mozilla_bugs/history.go). 
This bug live... And very bad, becouse its make impossible to use
window.history.go(-1) and need make construction such write path to return in
external variable and use window.location to return to work around this bug :( 
All javascript code writing before witch use window.history.go dont work in
Mozilla now :( But work in Netscape 4.* and MS explorer... Its a very, very  bad
bug :( Its near major :(
I see this in linux build 2001-04-11-08
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Priority: -- → P3
Summary: Java script window.history.go(-1) dont work → window.history.go(-1) does not work properly after a shift-reload
Target Milestone: --- → mozilla0.9.1
I tried this out in linux and windows today. Things work OK until you press
shift-reload. Resummarising. 
cc'ing jag. first of all, I see some problems with the back forward buttons.

1) follow the steps mentioned above . After you have reached the last page (step 
6), click back.
2) you will be taken to the page before it in hte sub-frame. But notice that the 
forward button is not enabled. It should be. If you look at the Go menu, you 
will see that the check mark is on the right entry and you can access the page 
ahead with the go menu. 

I noticed that UpdateBackForwardButtons() in navigator.js never gets called when 
this happens. Not sure if this is to do with the latest changes in Browser's 
WebProgressListener code.

*** This bug has been marked as a duplicate of 68847 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified dups
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.