Closed Bug 23051 Opened 25 years ago Closed 25 years ago

go back goes to last image

Categories

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

x86
Other
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: warrensomebody, Assigned: radha)

Details

In today's build, I brought up the browser to the mozilla.org page, clicked the "GNU Project" bookmark to to to the gnu page, then clicked some other bookmark, then I clicked the go back button. This took me to the http://www.gnu.org/graphics/gnu-head-sm.jpg image instead of the gnu project page.
Status: NEW → ASSIGNED
Target Milestone: M13
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Unable to reproduce this with today's build (works on both Windows and Linux). Reopen if you can reproduce it and we'll have to get more detailed instructions on how to make this happen.
Status: RESOLVED → REOPENED
This is happening on winNT build 2000010908 to me also. It's been happening for a little while now. I've found no clear way to reproduce this though. I'm trying to find a consistent way to make this happen - without luck so far.
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to reopen.
Seeing how no one has come up with a reproducible situation. I've got one, that happens more often than not; although it might seem unfair to Mozilla. :) Try this URL: http://dt034n04.san.rr.com/cgi-bin/nph-proxy.cgi/http/www.maximmag.com/ Click on Maxim Archive - note that you have to be fast, because the images all go away when you mouse over them. Now click back - and notice that the Sub Zero image has been loaded instead of the maxim homepage. My guess is this bug has something to do with bad javascript. Because the the proxy server you just went through implements a "proxy" on javascript calls also. That's why the images dissappear - because the proxy isn't letting the new images load. However none of that seems to explain why Mozilla's History is getting corrupted... I have a suspicion that the timing of some javascript call sequenced with the exit of the window is causing history corruption. By the way, that proxy is cgiproxy detailed info, as well as source can be found at http://www.jmarshall.com/tools/cgiproxy/ Also, the proxy is running on my home machine, sans security checks. I'll implement a username password soon enough. Look for that below if the link is asking for authentication.
Target Milestone: M13 → M14
Moving all to M14 (for webshell changes that are being deferred till M14 rather than destabilize M13).
This is a hard one to reproduce so I'm moving it out to M15. We ought not spend too much time till the new session history kicks in, anyway. I did manage to reproduce it (one time out of 3).
Target Milestone: M14 → M15
Component: Browser-General → History
Status: REOPENED → ASSIGNED
Target Milestone: M15 → M16
how is this to be repro'd now? This page: http://dt034n04.san.rr.com/cgi-bin/nph-proxy.cgi/http/www.maximmag.com/ doesn't see to be the same anymore does anybody have steps that even sometimes work?
QA Contact: nobody → claudius
i'm marking worksforme. i haven't seen this in a while, and I can't reproduce anymore at http://zoom.dyn.singleclick.net/cgi-bin/nph-proxy.cgi/http/www.maximonline.com/ either. I used winNT build 2000042608.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → WORKSFORME
Marking VERIFIED wfm
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.