2.92 KB, text/plain
If you have a frameset, for example: frameset parent document | +----> child one <frame> | +----> child two <frame> and script in 'child two' calls 'history.go(0)', then this will trigger a reload of the entire frameset (http://jrgm/cgi-bin/bugs/frameset-history-go/frameset.pl) In addition, all of the documents will be validated with the server which is contrary to Nav4.x behaviour, although apparently IE5.5 on win32 does validate (at least if it's been told 'no-cache').
By the way, the reason the headers in the testcase are Pragma: no-cache Cache-control: no-cache Content-type: text/html is that I was trying to see if Nav4.x would reload the frameset under any circumstance, but it does not. However, those flags are not required to demonstrate this bug in mozilla.
... and the expected condition in that testcase is that only the text/timers in the textbox in the lower document should update. Nothing else should change after the initial load of the document.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
I ran the test cases. I don't see a server validation when I use any of the links at the bottom frame, including history.go(0). Technically, I would say, history.go(0) is identical to a regular reload on the page. history.go(-1) is identical to history.back() OR clicking back button history.go(+1) is identical to history.forward() OR clicking forward history.go(N) (N being a number otehr than +1, -1, 0) is identical to going to any site using Go menu. When doing history.go(-1) only the subframe that had changed is reloaded because that is exactly what happened and that behavior is the identical to clicking on the back button. Since we have historically provided the "Frame reload" feature in our browsers and this frame reload is also used by layout to render pages with non-ascii charsets, window.location.reload() just reloads the frame instead of the whole page, whereas all JS history mechanisms are in sync with the overall window history. Yes, there are a few "out there" who rely on the old behavior. I have come across them as bugs. Those sites were requested to use window.location.reload() instead of history.go(0).
As described above, this is not a bug in N6.x. It is a deliberate change in behavior as compared to NS 4.x.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
marking VERIFIED Invalid. I think WontFix might've been a slightly more appropriate resolution though
Status: RESOLVED → VERIFIED
i'm rereading bugmail, the behavior described here is *so* counter intuitive. window.location.reload() to reload a frame history.go(0) to reload the whole frameset let's think about this: window is usually the window. and history is generally something that users can walk on a per frame basis (context menu: back, forward). so instead, we go and turn the behavior on its head. use the window object to reload a frame, and use an object that would logically apply to a page and make it apply to a window.
I disagree, timeless. At least about the window.location.reload() acting on the frame. You have to specify which window object (the frameset, or a frame) to reload, and that is the best way to go. As far as history.go(), I'm not sure which way to go on that. Is the history object associated with a particular window object, and if so, which one? Comment #4 in this bug sounds canonical. Therefore I'd have to agree with the INVALID marking. Sorry, timeless. I'm glad you cc'd me, but I don't see a strong enough basis for this as a bug. A change in behavior, yes, but not necessarily a bug.
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.