61176 - meta refresh ops take place after page changes on same site

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[allbery+moz]

If you go to the site named in the URL field (a Big Sister 0.38 installation),
you will load a set of frames, two of which autorefresh.  The largest will be on
a page which announces itself as "Servers"; the status pages that load into this
pane autorefresh every 60 seconds.

Click on any of the other status pages listed in the blue frame on the left.
These pages should also autorefresh... but the autorefresh reloads the "Servers"
page instead of your current page.  Netscape 4.x and IE5 refresh the current
page as expected.

I have reproduced this with the Win32, Linux, and Solaris nightly builds for the
past two weeks.

Comment 1

[allbery+moz]

One additional item:
if you go to a status page on a different host, such as one of the cluster
"slave" BigSister installations (select Clusters, then click on "Sun Cluster" in
the status frame; the other has restricted access), you will see that that page
autorefreshes correctly.  It appears that the fact that it is on a different
host is what causes mozilla to change its autorefresh information.

Comment 2

[allbery+moz]

Having visited the autorefreshing pages directly, it appears this bug is
specific to pages in frames:  if I visit
http://tully.ece.cmu.edu/bs/servers.html and then immediately to
http://tully.ece.cmu.edu/bs/core.html, the latter refreshes to itself and not to
servers.html.

It is possible that the fact that two frames autorefresh is involved:  the blue
frame on the left also refreshes every 60 seconds.

Comment 3

[Asa Dotzler [:asa]]

over to frames.  

Comment 4

[Ian Neal]

Seems to happen on a single frame refreshing site too http://shaunrose.com/
(click on webcam link and through to webcam page). Occasionally it does not
refresh back to the webcam page - maybe something to do with how far into
refresh period you click on another link?

Comment 5

[Alexey Zakhlestin]

2001011204

bug is still here.
Quite annoying, actually....

Comment 6

[Eric Pollmann]

I can reproduce this.

My guess is that this bug is a permutation of the loading/targetting problem.
That is, when the link is clicked, the *load* is occuring in the *initiating
frame*, not the *targetted frame*.  This cancels all previous loads (and pending
timers) in this frame, instead of the targetted frame.  I'll attach a testcase
that demonstrates this more clearly (3 files, last is actual test case).

Handing this one over to Rick who, I think, is looking at these issues.  (If
not, please feel free to hand it back!)

Comment 7

[Eric Pollmann]

Attachment: bottom frame

Comment 8

[Eric Pollmann]

Attachment: top frame

Comment 9

[Eric Pollmann]

Attachment: test case

Comment 10

[Eric Pollmann]

To use test case:

View test case attachment.  You will see two frames, top and bottom.  Both will
refresh every 5 seconds, and the displayed time will update to reflect this.

Click on the link in the top frame, which loads a new page (about:blank) into
the bottom frame.  This should stop the bottom frame from refreshing but should
*not* stop the top frame from refreshing.  Instead the opposite happens, the top
frame stops refreshing and the bottom continues along happily reloading.

This is because, when the page is loaded into the bottom frame, the *load* is
actually occuring in the top frame, and all existing loads (the coming refresh)
are cancelled in the top frame.  If the load were occuring on the bottom frame,
than pending loads in the bottom frame would be cancelled instead, which, I
think is what should happen.

Comment 11

[Boris Zbarsky [:bzbarsky]]

See also bug 65805

Comment 12

[Amarendra Hanumanula]

QA Contact update

Comment 13

[rpotts (gone)]

Fixed.  Patch is attached to bug #65777.

Comment 14

[Amarendra Hanumanula]

 Marking verified on Build ID # 2001-07-27-0.9.2