iFrames Appear to be Cached

• Component: Frames
• Status: RESOLVED FIXED

[David Wheeler]

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.

[David Wheeler]

Created attachment 2409 [details]
Test Case

[Chris Petersen]

 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.

[Benjamin Morin]

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. 

[Benjamin Morin]

Created attachment 3232 [details]
Example code

[Benjamin Morin]

This appears to not be a problem in Firefox 1.0.6.

[Alexey Proskuryakov]

In fact, it doesn't look like a restart is necessary - opening a new window makes Safari respect the new IFrame src.

[Alexey Proskuryakov]

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.

[Ben Jamieson]

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!

[Jonathan Steinert]

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.

[Eric Seidel (no email)]

bug 15554 sounds like the same bug.

[Luke Noel-Storr]

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.

[David Preece]

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

[Cameron Zwarich (cpst)]

*** Bug 15554 has been marked as a duplicate of this bug. ***

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

*** Bug 15486 has been marked as a duplicate of this bug. ***

[Cameron Zwarich (cpst)]

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.

[Mark Rowe (bdash)]

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?

[Cameron Zwarich (cpst)]

(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.

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

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.

[Maciej Stachowiak]

Comment on attachment 19977 [details]
Revised proposed patch

r=me

[Cameron Zwarich (cpst)]

Created attachment 19990 [details]
Revised proposed patch

Oops! The previous patch was missing a newline at the end of a file.

[Maciej Stachowiak]

Comment on attachment 19990 [details]
Revised proposed patch

r=me

[Brady Eidson]

Landed in r31264

[Alexey Proskuryakov]

*** Bug 18365 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 19441 has been marked as a duplicate of this bug. ***

[Sridhar Gurivireddy]

How come I still see this bug in Safari 3.1 on Windows (525.13.3)

[Mark Rowe (bdash)]

Because this bug was fixed after Safari 3.1 was released.

[Grace Kloba]

This happens again in the shipping Safari 3.2.1 (5525.27.1)

[Mark Rowe (bdash)]

The fix was not taken for Safari 3.2.x.

[Grace Kloba]

The nightly build also doesn't work. Where is the fix?

[Mark Rowe (bdash)]

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.

[Grace Kloba]

Sorry, you are right. The nightly build is working fine. I have both Safari opened which confused myself.

[Cameron Zwarich (cpst)]

*** Bug 9710 has been marked as a duplicate of this bug. ***