Closed Bug 44226 Opened 25 years ago Closed 25 years ago

Reload doesn't update session history.

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 40449

People

(Reporter: kinmoz, Assigned: radha)

References

()

Details

Attachments

(1 file)

To see this bug, you need to load a URL that sends back different text content during every load. Steps to reproduce: 1. Visit http://maug.mcom.com/cgi-bin/form.cgi 2. Note the date stamp on the page. 3. Press the reload button in the browser toolbar. 4. Note that the date stamp has updated to a more recent time. 5. Hit the browser back button. 6. Hit the browser forward button. 7. Notice that the page loaded displays the time stamp from the first load. I first noticed this bug when loading bugzilla queries from my bookmarks. Everytime I loaded a query from a bookmark, I kept getting out of date results, no matter where in the session history chain I was. The only way to ensure that I was seeing up to date data was to hit the reload button.
FYI I'm seeing this problem in the 2000062820 Commercial build.
Kin, I'm not sure I understand this right. Right now, when you hit relaod, docshell just picks up the current uri and initiates a normal load on it. Reloading by bypassing cache and/or proxy is not hooked up yet. What is the result you expect after step 4 and step 7.
I would expect to see the last version of the page I loaded.
*** Bug 44283 has been marked as a duplicate of this bug. ***
Since pages output by CGI do not have a last-modified header, there is no way to cache them in a reasonable manner. If passing this CGI script the same parameters results in a different result each time, how and why are the results of each supposed to be stored in cache and written to the session history?
See also bug 46014, on keywords not loading in bugzilla pages: if you load a bug, modify it and submit, then later go back and load the same bug, you'll see the original page, not the latest version.
*** Bug 41228 has been marked as a duplicate of this bug. ***
How does this differ from bug 40449?
marking tentative dup for now... *** This bug has been marked as a duplicate of 40449 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
VERIFIED Dupe. most cause the other is fixed and now so is this (with this test case)
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
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.

Attachment

General

Creator:
Created:
Updated:
Size: