Closed Bug 1139737 Opened 9 years ago Closed 9 years ago

Change inlined content of iframes in a local html file and reload, the content of the iframes is not updated

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
39 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: duanyao.ustc, Unassigned)

Details

Attachments

(1 file)

iframe-reload.html
460 bytes, text/html
Details
Attached file iframe-reload.html — 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150222232811

Steps to reproduce:

Create a html with such content:
    <iframe width="700px" height="100px" srcdoc="A"></iframe>
    <iframe width="700px" height="100px" src="data:,A"></iframe>

load the html via file-url (http-url doesn't trigger this bug).

Change srcdoc="A" to srcdoc="B", and src="data:,A" to src="data:,B", save, and hit "reload" button of your browser.

You can download the attachment to reproduce.



Actual results:

Firefox still shows "A" in both iframes after change the file and reload.


Expected results:

Firefox should show "B" in both iframes after change the file and reload.
A non-forced reload will reload each frame individually, preserving whatever URL they were navigated to, instead of just reloading the toplevel page and ignoring subframes.  This is very much by design.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
But if you load the file via http-url, changing srcdoc/src and reloading DOES cause updating of iframes' content. Why file-url and http-url are different here?

PS. google chrome always update iframes after changing and reloading the file, not matter it is loaded via file-url or http-url.
> But if you load the file via http-url, changing srcdoc/src and reloading DOES cause
> updating of iframes' content.

Odd.  It shouldn't, if I follow the code correctly.
(In reply to Not doing reviews right now from comment #3)
> > But if you load the file via http-url, changing srcdoc/src and reloading DOES cause
> > updating of iframes' content.
> 
> Odd.  It shouldn't, if I follow the code correctly.

My http server is node.js+express, and I tested FF 36, 38, and 39, same result.
OK, I just tested with this basic Python web server (straight out of the example at <https://docs.python.org/2/library/simplehttpserver.html>):

----------------------------------------------------
import SimpleHTTPServer
import SocketServer

PORT = 8000

Handler = SimpleHTTPServer.SimpleHTTPRequestHandler

httpd = SocketServer.TCPServer(("", PORT), Handler)

print "serving at port", PORT
httpd.serve_forever()
----------------------------------------------------

and this HTML file:

  <iframe src="data:text/plain,a"></iframe>
  <iframe srcdoc="b"></iframe>

and the result is as I expect: I load http://localhost:8000/path/to/file, I see "a" and "b" in the iframes.  I edit the file to have "c" and "d" instead, reload, still see "a" and "b".  I force-reload, I see "c" and "d".

So what's different in your situation?  If you try the above locally, what behavior do you see?  If you see the same thing as I do, I guess we get to figure out what's different about your node.js+express server....

Also, just to make sure, you see the reload-every-time behavior on the node.js+express server in a clean profile with no extensions?
Yes, python SimpleHTTPServer and node.js+express server make the difference, and the python server makes iframe not updating; a clean profile makes no difference.

I investigated the requests/response headers by devtools:

===============================

node.js+express

Host: localhost:8088
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: connect.sid=s%3AXkqzDLbpfgVABk43X6PsCYsO.kao2a9DpPbaSqvOddAp9eUP17bCXjSnXqkVbAZGg9S0
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Accept-Ranges: bytes
Cache-Control: public, max-age=0
Connection: keep-alive
Content-Length: 464
Content-Type: text/html; charset=UTF-8
Date: Thu, 05 Mar 2015 06:04:50 GMT
Etag: "464-1425535294000"
Last-Modified: Thu, 05 Mar 2015 06:01:34 GMT
X-Powered-By: Express

==========================

python SimpleHTTPServer

Host: localhost:8081
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Content-Length: 464
Content-Type: text/html
Date: Thu, 05 Mar 2015 06:07:01 GMT
Last-Modified: Thu, 05 Mar 2015 06:01:34 GMT
Server: SimpleHTTP/0.6 Python/2.7.9

==============================

You see, in both case the cache is disabled, so I don't see much difference. Can Etag in express causes the behavior?
(In reply to Not doing reviews right now from comment #1)
> This is very much by design.

After some more thought, I still think this is an undesired feature.

If I have modified my html files on the server, I expect my users can hit "reload" to get the latest version. However if a file contains iframe, hitting "reload" will get an odd half-updated version. How can I tell my users "you must shift-reload the page if you are using firefox"? Many users never hear about the difference between forced and non-forced reloading.
Another problem of this feature is, browser doesn't know which iframe in the updated file is corresponding to which iframe in the old file. For example, in the old file:

    <iframe id="A" srcdoc="A"></iframe>
    ...
    <iframe id="B" srcdoc="B"></iframe>

in the new file, the author swapped the two iframes:

    <iframe id="B" srcdoc="B"></iframe>
    ...
    <iframe id="A" srcdoc="A"></iframe>

Users hit "reload", and the browser makes a wrong guess: it loads content "A" into iframe#B, and "B" into iframe#A.

So I'd like to remove this "feature".
> If I have modified my html files on the server

The problem is, this is not the common case of "reload".  The common case is the user loads a page, clicks some links, which may navigate subframes, then for some reason does a reload (most commonly because the page has script calling location.reload()).  The actual page was not modified in any way.

At that point, we don't want to lose the subframe navigations the user performed, so we reload each subframe with its pre-reload URI as opposed to the src it has.

Now clearly there are cases like yours in which this heuristic fails.  The question is which case is more common.

I believe we have bug reports requesting that if the reload got different HTML (whatever that means) then we should ignore the old frame information, for what it's worth.
(In reply to Not doing reviews right now from comment #9)
> I believe we have bug reports requesting that if the reload got different
> HTML (whatever that means) then we should ignore the old frame information,
> for what it's worth.

This request sounds reasonable. A quick test with IE 11 shows that it reloads sub-frames if the parent html file is modified and reloaded. I believe FF should at least do this as well.

I found these similar bugs are still open: 
https://bugzilla.mozilla.org/show_bug.cgi?id=356558
https://bugzilla.mozilla.org/show_bug.cgi?id=363840
So I think this bug may be duplicated, but not invalid.

P.S. I found that it is the "Cache-Control: max-age=0" header from my node.js+express server that causes FF to reload iframes every time, and Etag is irrelavent. This is also confirmed by a apache 2.4 server. Note that FF may not reload iframes if the file was sent with max-age > 0 and later sent with max-age = 0, even if you restart FF in between. You'll have to restart FF again or open a new tab. Why max-age affects reloading of sub-frames?
> A quick test with IE 11 shows that it reloads sub-frames if the parent html file is
> modified and reloaded.

What does it do if the parent file had expired from cache, so had to be refetched, but came back exactly the same as before?

> Why max-age affects reloading of sub-frames?

I don't know offhand; it doesn't seem like it should.  Nothing in the code that does the reload session history bits looks at max-age.  I'd need to do some debugging to figure out what's going on there.

(In reply to Not doing reviews right now from comment #11)
> > A quick test with IE 11 shows that it reloads sub-frames if the parent html file is
> > modified and reloaded.
> 
> What does it do if the parent file had expired from cache, so had to be
> refetched, but came back exactly the same as before?
> 
IE 11 reload subframes in this case. It seems it restore subframes only if http status 304 is returned for the parent file.
Yeah, that's way too restrictive for common user situations...
So how about my suggestion in this bug #363840 :

I think you can save Etag and Last-Modified headers within history entries. When a top-level page is reloaded, compare Etag or Last-Modified in its history entry and those in the server response. If they are not match, reload all subframes, otherwise restore subframes from history. This is independent from cache.
Yes, that sounds like it might be workable.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: