Bug 3580 - iFrames Appear to be Cached
: iFrames Appear to be Cached
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: Frames
: 412
: Macintosh Mac OS X 10.4
: P2 Normal
Assigned To: Cameron Zwarich (cpst)
: HasReduction
Depends on:
Blocks: 15554
  Show dependency treegraph
 
Reported: 2005-06-16 16:53 PDT by David Wheeler
Modified: 2009-04-21 01:13 PDT (History)
14 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description David Wheeler 2005-06-16 16:53:16 PDT
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 David Wheeler 2005-06-16 16:54:21 PDT
Created attachment 2409 [details]
Test Case
Comment 2 Chris Petersen 2005-06-16 20:33:20 PDT
 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 Benjamin Morin 2005-08-05 11:28:53 PDT
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 Benjamin Morin 2005-08-05 11:31:17 PDT
Created attachment 3232 [details]
Example code
Comment 5 Benjamin Morin 2005-08-05 11:33:06 PDT
This appears to not be a problem in Firefox 1.0.6.
Comment 6 Alexey Proskuryakov 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 Alexey Proskuryakov 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 Ben Jamieson 2006-07-04 13:34:16 PDT
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 Jonathan Steinert 2007-07-06 17:20:27 PDT
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 Eric Seidel 2007-10-18 02:24:07 PDT
bug 15554 sounds like the same bug.
Comment 11 Luke Noel-Storr 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 David Preece 2008-03-09 20:14:48 PDT
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 Cameron Zwarich (cpst) 2008-03-21 18:44:58 PDT
*** Bug 15554 has been marked as a duplicate of this bug. ***
Comment 14 Cameron Zwarich (cpst) 2008-03-22 02:34:19 PDT
Created attachment 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 Cameron Zwarich (cpst) 2008-03-22 02:34:41 PDT
*** Bug 15486 has been marked as a duplicate of this bug. ***
Comment 16 Cameron Zwarich (cpst) 2008-03-22 02:50:30 PDT
Created attachment 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 Mark Rowe (bdash) 2008-03-22 15:43:17 PDT
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 Cameron Zwarich (cpst) 2008-03-22 16:09:55 PDT
(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 Cameron Zwarich (cpst) 2008-03-22 20:27:29 PDT
Created attachment 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 Cameron Zwarich (cpst) 2008-03-22 22:01:14 PDT
Created attachment 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 Maciej Stachowiak 2008-03-23 19:33:05 PDT
Comment on attachment 19977 [details]
Revised proposed patch

r=me
Comment 22 Cameron Zwarich (cpst) 2008-03-23 20:41:26 PDT
Created attachment 19990 [details]
Revised proposed patch

Oops! The previous patch was missing a newline at the end of a file.
Comment 23 Maciej Stachowiak 2008-03-23 22:28:26 PDT
Comment on attachment 19990 [details]
Revised proposed patch

r=me
Comment 24 Brady Eidson 2008-03-24 17:39:23 PDT
Landed in r31264
Comment 25 Alexey Proskuryakov 2008-04-09 00:17:15 PDT
*** Bug 18365 has been marked as a duplicate of this bug. ***
Comment 26 Alexey Proskuryakov 2008-06-10 08:39:00 PDT
*** Bug 19441 has been marked as a duplicate of this bug. ***
Comment 27 Sridhar Gurivireddy 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 Mark Rowe (bdash) 2008-12-11 16:27:50 PST
Because this bug was fixed after Safari 3.1 was released.
Comment 29 Grace Kloba 2008-12-11 16:36:43 PST
This happens again in the shipping Safari 3.2.1 (5525.27.1)
Comment 30 Mark Rowe (bdash) 2008-12-11 16:37:09 PST
The fix was not taken for Safari 3.2.x.
Comment 31 Grace Kloba 2008-12-11 17:00:13 PST
The nightly build also doesn't work. Where is the fix?
Comment 32 Mark Rowe (bdash) 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 Grace Kloba 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 Cameron Zwarich (cpst) 2009-04-21 01:13:29 PDT
*** Bug 9710 has been marked as a duplicate of this bug. ***