221584 - Shift+Reload doesn't reload iframes

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Jonathan Bartlett]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

On several platforms, Shift+Reload on a page does not reload it's iframes.

Reproducible: Always

Steps to Reproduce:
1.Load a page with iframes
2.Change the iframe page
3.Shift+Reload

Actual Results:  
iframe did not change

Expected Results:  
iframe should have shown modified iframe page

I haven't downloaded the latest Mozilla (still on 1.4 and 1.4Alpha), but I
searched bugzilla and didn't find the info.

Comment 1

[Boris Zbarsky [:bzbarsky]]

darin, shouldn't this just work automatically because the loadgroup gets the
relevant loadflags from the document channel and all other channels inherit them?  

Comment 2

[Boris Zbarsky [:bzbarsky]]

Actaully, it looks like the loadgroup we end up using is not the loadgroup of
the parent page, since each frame gets its own loadgroup...

Should the code that kicks off this load be manually transferring load flags a
la imagelib then?

Comment 3

[Darin Fisher]

wow.. i didn't realize that each frame gets its own loadgroup.  that seems wierd
and wrong since the load group's "groupObserver" is the guy who drives
nsIWebProgressListeners.  it seems wrong to have more than one of those per
browser window (or per tab).  maybe the solution is to make each iframe grab a
reference to _the_ load group instead of creating a new one.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I could be wrong... this mess of docloaders, docshells, "loadcookies", etc is
pretty untraceable...  In any case, I'll test this tonight to make sure.

Part of the problem, I think, is that the frame has its own onload event, so it
needs to keep track of its own loads.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, each frame/iframe has its own loadgroup.  Is there a way they could use
the same loadgroup but have separate onload events?  Where's rpotts when we need
him?  And what's the right component for this mess?  ;)

Comment 6

[Darin Fisher]

wow!  but, it is true that the body's onload will always be deferred until after
all frames are finished loading, right?  in that case, how does that work? 
could it be the case that the frame's loadgroup is added to the toplevel
loadgroup?  (if not, then is that perhaps the solution to this bug?)

Comment 7

[Boris Zbarsky [:bzbarsky]]

> the body's onload will always be deferred

Right. onload is triggered by docloaders, and docloaders are aware of the
parent/child relationship between frames.  See
nsDocLoaderImpl::DocLoaderIsEmpty() and the way it calls up to the parent.

We could certainly try adding the loadgroup to the parent, but at the moment I'm
having trouble reproducing the bug (hence have no way of testing possible
fixes).    Jonathan, is there a page that shows the problem that you could point
me to?

Comment 8

[Jonathan Bartlett]

Hmmm... trying from home, a simple test case did not reproduce the bug, but I'm
on 1.2.1 here.  I'll retry from work tomorrow and see if I can reproduce it with
a simple test case.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Thanks!  Note that it need not be a simple testcase as long as it's publicly
available, since we have an idea of what's causing the bug and just need
something to test possible fixes on....

Comment 10

[Jonathan Bartlett]

Sorry guys.  I can't seem to make a reproducible test case.  I know this
happened to us, because it took us about 20 minutes to figure out why a reload
wasn't working on our computers.   I'm going to close this until I can make a
real test case.  Sorry for the goose chase.  

Comment 11

[Phil Endecott]

I've encountered this problem with FF1.0.  Since it was closed due to the
absence of a working test case I have constructed a demo in the hope that it
will help you to fix it.  Can someone with the necessary permissions reopen the bug?

I will attach the testcase as a tar file, but it is also live on my server.  If
you decide to use the contents of the tar file take care about the file
permissions *and ownership* - ask me if it doesn't work for you.  The online
version is at http://belize.chezphil.org/bugreps/shreloadiframe/.

The demo consists of inner.txt, a text file containing a random number, and
outer.html, a simple page that includes inner.txt in an iframe.  Then there are
two CGI scripts that change inner.txt, giving it new random contents.  One
updates its last-modified time in the usual way while the other changes the
content without altering the last-modified time.  You can invoke them using
buttons in ctrls.html - it's best to have two windows open, one with ctrls.html
and another with either inner.txt or outer.html.

There are then 8 combinations of 3 variables:
- viewing inner.txt "raw" or within outer.html's iframe
- doing a normal reload or a shift-reload
- changing the contets with or without changing the modification time.

What we expect to see is that either type of reload will get the new content if
the modification time has been changed, while only a shift-reload will get the
new content if the modification time has not been changed:

Mod time changed?    Type of reload         New content seen?
Yes                  Normal                 Yes
Yes                  Shift                  Yes
No                   Normal                 No
No                   Shift                  Yes

This is exactly what we see if we view inner.txt directly.  However, if we view
it embedded in outer.html's iframe, we get:

Mod time changed?    Type of reload         New content seen?
Yes                  Normal                 Yes
Yes                  Shift                  Yes
No                   Normal                 No
No                   Shift                  *** No ***

Checking the server log we see this for this last incorrect case:

62.253.128.12 - - [19/Feb/2005:22:13:05 +0000] "GET
/bugreps/shreloadiframe/outer.html HTTP/1.1" 200 118 "-" "Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)"
62.253.128.12 - - [19/Feb/2005:22:13:05 +0000] "GET
/bugreps/shreloadiframe/inner.txt HTTP/1.1" 304 -
"http://belize.chezphil.org/bugreps/shreloadiframe/outer.html" "Mozilla/5.0
(X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package
1.0-2)"

Observe that outer.html returns a 200 status code, while inner.txt returns a 304
"not modified".  Apache can only possibly return a 304 if Moz sent it an
if-none-match / if-modified-since request, which is exactly what it shouldn't be
doing when you press Shift.

There's similar evidence in the  NSPR_LOG_MODULES=nsHttp:3 debug output:

1084522752[809d868]: http request [
1084522752[809d868]:   GET /bugreps/shreloadiframe/outer.html HTTP/1.1
1084522752[809d868]:   Host: belize.chezphil.org
1084522752[809d868]:   User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
1084522752[809d868]:   Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
1084522752[809d868]:   Accept-Language: en-gb,en;q=0.5
1084522752[809d868]:   Accept-Encoding: gzip,deflate
1084522752[809d868]:   Accept-Charset: UTF-8,*
1084522752[809d868]:   Keep-Alive: 300
1084522752[809d868]:   Connection: keep-alive
1084522752[809d868]:   Pragma: no-cache
1084522752[809d868]:   Cache-Control: no-cache
1084522752[809d868]: ]
1114729392[810ea58]: http response [
1114729392[810ea58]:   HTTP/1.1 200 OK
1114729392[810ea58]:   Age: 0
1114729392[810ea58]:   Date: Sat, 19 Feb 2005 22:30:27 GMT
1114729392[810ea58]:   Content-Length: 118
1114729392[810ea58]:   Content-Type: text/html
1114729392[810ea58]:   Server: Apache/2.0
1114729392[810ea58]:   Last-Modified: Sat, 19 Feb 2005 20:36:49 GMT
1114729392[810ea58]:   Etag: "45583-76-30b6da40"
1114729392[810ea58]: ]
1084522752[809d868]: http request [
1084522752[809d868]:   GET /bugreps/shreloadiframe/inner.txt HTTP/1.1
1084522752[809d868]:   Host: belize.chezphil.org
1084522752[809d868]:   User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
1084522752[809d868]:   Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
1084522752[809d868]:   Accept-Language: en-gb,en;q=0.5
1084522752[809d868]:   Accept-Encoding: gzip,deflate
1084522752[809d868]:   Accept-Charset: UTF-8,*
1084522752[809d868]:   Keep-Alive: 300
1084522752[809d868]:   Connection: keep-alive
1084522752[809d868]:   Referer:
http://belize.chezphil.org/bugreps/shreloadiframe/outer.html
1084522752[809d868]:   If-Modified-Since: Sat, 19 Feb 2005 22:24:13 GMT
1084522752[809d868]:   If-None-Match: "455bd-10-b0ce7d40"
1084522752[809d868]: ]
1114729392[810ea58]: http response [
1114729392[810ea58]:   HTTP/1.1 304 Not Modified
1114729392[810ea58]:   Etag: "455bd-10-b0ce7d40"
1114729392[810ea58]:   Date: Sat, 19 Feb 2005 22:29:28 GMT
1114729392[810ea58]: ]

Although I have normally seen an If-Modified-Since / If-None-Match as above I
have also observed it sending no request at all for inner.txt on shift-reload.

I hope this is what you need to start investigating this - let me know if there
is any way I can help further.  This URL should be fairly permanent, but let me
know if know if anything bitrots.

Regards, Phil.

Comment 12

[Phil Endecott]

Attachment: Testcase as described

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, reopening.

On shift+reload, we don't load the iframe from history, but we also don't
propagate the BYPASS_* flags down to it (it's just loaded via normal loadURI).

Perhaps when loading a subframe we should check the load type of the parent if
the parent is still loading, and if it is we should propagate any BYPASS_* flags
to our own loadtype?

Comment 15

[Tony Mechelynck [:tonymec]]

No activity since Feb. 2005 (except for getting a dup).

I'm moving this bug to Core on the assumption that it's there that it ought to be fixed, and boldly changing it from PC/Linux to All/All without checking (I'm on Linux myself). (Please change back if Windows & Mac are not addected.)