Back button behavior has changed again in Safari 3.1, after doing a dom update via ajax/RJS

Rails
1

GAH!

Here is the firefox behavior, which is perfect:

  1. View page 1
  2. Update some text by using link_to_remote or remote_form_for, along
    with an RJS replace or replace_html
  3. Navigate to page 2
  4. Hit back
  5. 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.

Advice appreciated.

2

I have tried adding various caching headers to the response object
with no success.

3

Anyone else encountering this? It appears to be a history issue, as
cache settings have had no effect.

4

Do you have a small, reproducible test case for this?

5

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.

6

I’ll put together a small code sample.

7

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…