Bug 3580 - iFrames Appear to be Cached
: iFrames Appear to be Cached
Status: RESOLVED FIXED
: WebKit
Frames
: 412
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To:
:
: HasReduction
:
: 15554
  Show dependency treegraph
 
Reported: 2005-06-16 16:53 PST by
Modified: 2009-04-21 01:13 PST (History)


Attachments
Test Case (116 bytes, text/plain)
2005-06-16 16:54 PST, David Wheeler
no flags Details
Example code (3.16 KB, application/zip)
2005-08-05 11:31 PST, Benjamin Morin
no flags Details
Proposed patch (1.44 KB, patch)
2008-03-22 02:34 PST, Cameron Zwarich (cpst)
no flags Review Patch | Details | Formatted Diff | Diff
Revised proposed patch (1.58 KB, patch)
2008-03-22 02:50 PST, Cameron Zwarich (cpst)
no flags Review Patch | Details | Formatted Diff | Diff
Revised proposed patch (7.21 KB, patch)
2008-03-22 20:27 PST, Cameron Zwarich (cpst)
no flags Review Patch | Details | Formatted Diff | Diff
Revised proposed patch (8.48 KB, patch)
2008-03-22 22:01 PST, Cameron Zwarich (cpst)
mjs: review+
Review Patch | Details | Formatted Diff | Diff
Revised proposed patch (8.36 KB, patch)
2008-03-23 20:41 PST, Cameron Zwarich (cpst)
mjs: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-06-16 16:53:16 PST
If I have a page with an iFrame, and I change the iFrame and reload, the iframe
will not change.

For example, in the test case that I will shortly attach, there is an iframe
pointing to www.apple.com. Load this page into Safari. Then change its src to
www.google.com and reload the page. The iframe will still display www.apple.com
unless you restart Safari.
------- Comment #1 From 2005-06-16 16:54:21 PST -------
Created an attachment (id=2409) [details]
Test Case
------- Comment #2 From 2005-06-16 20:33:20 PST -------
 I saved this test case locally and opened it Safari. While the test case in loaded in Safari, I changed the  
iframe src in a text editor. If I reload this page, the previous src is still used. This reproduces in Mac 
Firefox 1.0.4 too. But if I hold down shift key and press the reload toolbar icon in Firefox, the iframe will 
use the newer src.
------- Comment #3 From 2005-08-05 11:28:53 PST -------
I have an additional example of this behavior here http://www.s-seven.net/iframe_test.php and will also 
attach the source for it.  The behavior is exactly as described in the original post.  Safari initially loads the 
page, the iframe src is loaded.  In this example, the src is changed through a form action that is submitted 
by javascript in the body's onload event.  Upon refresh, the expected behavior would be the initial src to 
load, but instead, the modified src is loaded first and then a second time when the body's onload executes 
on the refreshed page. 
------- Comment #4 From 2005-08-05 11:31:17 PST -------
Created an attachment (id=3232) [details]
Example code
------- Comment #5 From 2005-08-05 11:33:06 PST -------
This appears to not be a problem in Firefox 1.0.6.
------- Comment #6 From 2006-02-08 12:56:32 PST -------
In fact, it doesn't look like a restart is necessary - opening a new window makes Safari respect the new IFrame src.
------- Comment #7 From 2006-02-08 13:26:55 PST -------
By the way, there is an error reported in JavaScript console:

Unsafe JavaScript attempt to access frame with URL file:///Users/ap/Desktop/try.html from frame with URL http://www.apple.com/. Domains must match.
------- Comment #8 From 2006-07-04 13:34:16 PST -------
I am experiencing the same issue. Tis makes some web apps unusable (specifically one I am writing!)

As more an more web apps use iframes, this is going to impact Safari users more and more.

Please fix it!
------- Comment #9 From 2007-07-06 17:20:27 PST -------
We're running into this bug at my work as well.

As a workaround, we are setting the 'id' on the iframe entity to a unique string. This appears to effectively break the caching that is happening on the iframe.

I've got a demo of it at http://hachi.kuiki.net/bug_reports/20070706-webkit-iframe-src/

demo.pl will render 3 iframes, and if you reload it the words will eventually not line up in order. viewing the source will reveal that the source of the page isn't actually being rendered, nor is a cached version of the page.

Calling demo.pl?id will demonstrate the cache bust technique we use.

Finally, demo.perl is the source to the demo.pl script, and there are the 3 iframe source files as well.
------- Comment #10 From 2007-10-18 02:24:07 PST -------
bug 15554 sounds like the same bug.
------- Comment #11 From 2007-11-16 00:47:51 PST -------
I encountered this bug when trying to develop a Facebook application.

It seems a pretty major bug, I'm surprised it's been sitting around for so long without being fixed.
------- Comment #12 From 2008-03-09 20:14:48 PST -------
I think I also have this problem: I have an iframe that's dynamically created by a piece of javascript that's triggered by an onLoad event. First time through the iframe's address is created correctly...

http://skitch.com/rantydave/8xy1/conversation

But on pressing refresh WebKit re-fetches the javascript correctly but then falsely assumes that the URL of the frame has not changed.

http://skitch.com/rantydave/8xy5/conversation

Running 5523.15 on 10.5.2
------- Comment #13 From 2008-03-21 18:44:58 PST -------
*** Bug 15554 has been marked as a duplicate of this bug. ***
------- Comment #14 From 2008-03-22 02:34:19 PST -------
Created an attachment (id=19966) [details]
Proposed patch

Here is a patch that fixes this bug. The problem is that when a WebFrame was loading a URL into a child, there were certain conditions under which it would take the URL from a history item (such as back/forward navigation), and one of these conditions was when it was a reload. This is always incorrect behaviour, at least as far as I can tell.

This patch also fixes bug 15554 and bug 15486.

I am not quite sure how to make a test for this. Perhaps script an HTTP test? It might be more effort than it is worth for now.
------- Comment #15 From 2008-03-22 02:34:41 PST -------
*** Bug 15486 has been marked as a duplicate of this bug. ***
------- Comment #16 From 2008-03-22 02:50:30 PST -------
Created an attachment (id=19968) [details]
Revised proposed patch

I forgot to mention bug 15486 in the ChangeLog, because I made the diff before I tested against that bug. I should also note that this patch causes no change in layout test results.
------- Comment #17 From 2008-03-22 15:43:17 PST -------
It sounds like this would mean that hitting "Reload" on a page containing frames would no longer reload the frames you have navigated to, but would instead reload the original frame URLs.  Is that really desirable behaviour?
------- Comment #18 From 2008-03-22 16:09:55 PST -------
(In reply to comment #17)
> It sounds like this would mean that hitting "Reload" on a page containing
> frames would no longer reload the frames you have navigated to, but would
> instead reload the original frame URLs.  Is that really desirable behaviour?

The patch does what you suspect. But so do Firefox (version 2 and the version 3 beta) and Opera (version 9.26 and the version 9.50 beta). I don't have IE to check.

I am almost done writing an HTTP test for this, and will upload a new patch soon.
------- Comment #19 From 2008-03-22 20:27:29 PST -------
Created an attachment (id=19976) [details]
Revised proposed patch

Here is the patch with tests. I only have tests for the iframe and object elements, not for actual subframes in a frameset. I could add one as well before this lands. Unfortunately, when the tests are run together, reload-subframe-object fails. I haven't yet tracked down the reason for this.
------- Comment #20 From 2008-03-22 22:01:14 PST -------
Created an attachment (id=19977) [details]
Revised proposed patch

The problem with the tests in the last patch was that I wasn't clearing whitespace from the cookies, and the cookies persist between tests. I fixed that and added a test for frames in a frameset, now covering all three kinds of subframes.
------- Comment #21 From 2008-03-23 19:33:05 PST -------
(From update of attachment 19977 [details])
r=me
------- Comment #22 From 2008-03-23 20:41:26 PST -------
Created an attachment (id=19990) [details]
Revised proposed patch

Oops! The previous patch was missing a newline at the end of a file.
------- Comment #23 From 2008-03-23 22:28:26 PST -------
(From update of attachment 19990 [details])
r=me
------- Comment #24 From 2008-03-24 17:39:23 PST -------
Landed in r31264
------- Comment #25 From 2008-04-09 00:17:15 PST -------
*** Bug 18365 has been marked as a duplicate of this bug. ***
------- Comment #26 From 2008-06-10 08:39:00 PST -------
*** Bug 19441 has been marked as a duplicate of this bug. ***
------- Comment #27 From 2008-12-11 16:23:21 PST -------
How come I still see this bug in Safari 3.1 on Windows (525.13.3)
------- Comment #28 From 2008-12-11 16:27:50 PST -------
Because this bug was fixed after Safari 3.1 was released.
------- Comment #29 From 2008-12-11 16:36:43 PST -------
This happens again in the shipping Safari 3.2.1 (5525.27.1)
------- Comment #30 From 2008-12-11 16:37:09 PST -------
The fix was not taken for Safari 3.2.x.
------- Comment #31 From 2008-12-11 17:00:13 PST -------
The nightly build also doesn't work. Where is the fix?
------- Comment #32 From 2008-12-11 17:02:00 PST -------
The fix is in the nightly build.  If you think it is not working, please file a new bug report and provide precise steps on how to reproduce the problem.
------- Comment #33 From 2008-12-12 09:55:58 PST -------
Sorry, you are right. The nightly build is working fine. I have both Safari opened which confused myself.
------- Comment #34 From 2009-04-21 01:13:29 PST -------
*** Bug 9710 has been marked as a duplicate of this bug. ***