109834 - history.go(0) in a frameset child document will reload whole frameset (and validate at server)

Status: VERIFIED INVALID

(Core :: DOM: Navigation, defect)

Description

[John Morrison]

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').

Comment 1

[John Morrison]

Attachment: three source files for the testcase (if anyone really cares)

Comment 2

[John Morrison]

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.

Comment 3

[John Morrison]

... 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. 

Comment 4

[Radha on family leave (not reading bugmail)]

jrgm:  The behavior you see is the expected behavior for Netscape 6.0 and above.
we broke away from the NS4.x behavior in this case. Frame specific javascript
history is not supported anymore for modularity and easy managebility of
history.  Frame specific navigations are tied to the  window's session history.
so history.go()/back()/forward() will perform those operations on the whole
window. The change in behavior is not very obvious in
history.back(),history.forward() and history.go(a non-zero number).  However it
is noticeble in history.go(0). If you are looking for a frameset specific
reload, I suggest that you use, location.reload() which will be performed on the
frameset only. 

However, when history.go(0) is performed on the whole page, I do not expect a
server validation. It should fetch it from cache. I will look in to that. 

Comment 5

[John Morrison]

Hmm, I could have sworn that this was pinging the server in the build 
i was using (yesterday's trunk) but a current build is not validating on 
history.go(-1|0|1) or history.back/history.forward(). (Maybe it was the 
no-cache case that I wasn't sure about whether back/forward should validate
no-cache stuff). 

See either 
  http://jrgm/cgi-bin/bugs/109834/top.pl
  http://jrgm.mcom.com/bugs/109834/frameset/top.html
and do 'tail -f /etc/httpd/logs/access_log' on jrgm.mcom.com

But, I'm not sure I quite get why 'history.go(0)' is producing something 
different from 'history.go(N)' with N not equal to zero. Specifically, the 
history.go(0) will cause javascript in all the frames to be recompiled and 
executed, whereas history.go(-1) will cause only the current frame where that 
call was made to retrigger the JS. 

I'm just wondering if someone "out there" is depending on retaining state in  
the other frames when they do 'history.go(0)' to reload the current frame. 
I could see someone actually relying on this old behaviour, and having some 
application blow up because of it (noting that history.go(0) was the way to 
do window.location.reload() in the first release of JS, and some habits die 
hard). 

[By the way, I noticed this behaviour while working on bug 108984, although
that bug is something different (slow because of  bad string usage coupled 
with a security fix that slowed down property access].]

Comment 6

[Radha on family leave (not reading bugmail)]

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).

Comment 7

[Radha on family leave (not reading bugmail)]

As described above, this is not a bug in N6.x. It is a deliberate change in
behavior as compared to NS 4.x.  

Comment 8

[Claudius Gayle]

marking VERIFIED Invalid. I think WontFix might've been a slightly more
appropriate resolution though

Comment 9

[timeless]

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.

Comment 10

[Alex Vincent [:WeirdAl]]

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.