Update some text by using link_to_remote or remote_form_for, along
with an RJS replace or replace_html
Navigate to page 2
Hit back
Page was cached with dom updates, note that the page is show in the
same state as it was left
Safari 3.0 behavior
1…4) repeat
5) Page reloads, ending up in the state where it was left
Safari 3.1 behavior:
1…4) repeat
5) Page was cached WITHOUT dom updates, page is shown in unaltered
state until refresh is hit
I thought I’d give it a shot with changing my status inline on
facebook, then navigating away and back, and noticed that the page
does reload and the dom updates are there.
Ouch. After much testing, I think I’ve found the problem:
I have an iframe in my layout appliation.html.erb, which I use with
attachment_fu and responds_to_parent for ajaxy uploading of
attachments. It’s required for my app. Funny enough, the first place I
read about the iFrame remoting pattern was on Apple’s site, but now
it’s Apple’s browser that seems to have a problem with it.
It looks like this:
The iFrame appears to be forcing the page to load in its original
state when clicking back to it after navigating away. Not sure what to
do at this point but will keep at it.
Well, I’ve managed to get around the problem by dynamically creating
and destroying the iframe via a javascript onsubmit for the requisite
forms. Problem solved for now. Though I have noticed other instances
of safari history weirdness related to ajax that are unrelated to the
iframe issue. The fun continues…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.