IE6 not repopulating form fields on back button in Ruby on Rails a

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have some forms in a Ruby on Rails app. If the user types some values into
a form, leaves the page and then returns by pressing the back button, IE
should repopulate the form to the last values automatically. It does so
correctly for all web forms that I have created, except for the ones inside a
Ruby on Rails application. I am trying to use this repopulate behavior to
maintain state information across page views in an AJAX application - a
relatively common practice.

I have a sample page here that works properly for both Firefox and IE6:
http://www1.zvents.com/test.rhtml

If you reload that page, or navigate away and return through the back
button, it retrieves a "stored" value because the browser correctly
repopulates the form.

However, if I move the exact same form inside Ruby on Rails, IE6 no longer
repopulates the form (though Firefox does):
http://www1.zvents.com/events/test

If you do a page source, you'll notice that the 2 pages are identical. So,
I'm a little stumped. Anyone know why the repopulate behavior is different
between these 2 examples?

Thanks in advance!

Tyler
 
Hi Tyler,

I get a "page does not exist" message on each of those pages--give a shout
if you get them online again and I can take a look at them.

In the meantime... You mentioned that the page source is identical for the
two pages, but what about the HTTP headers? I'll bet that is where the
difference is.

Ethereal (http://www.ethereal.com/) would be a good tool for looking at
this. If I'm just working in Firefox I usually use Live HTTP Headers
(http://livehttpheaders.mozdev.org/) - in fact that may be all you need -
but Ethereal will work with both IE and Firefox. Microsoft has something new
called Fiddler (http://www.fiddlertool.com/) that I've been meaning to try
out too.

A couple of Ethereal tips...

If you try to capture with a wireless card and don't get any packets, turn
off promiscuous mode for that card. Promiscuous mode lets you capture all
traffic, not just your own, but it doesn't work with all wireless cards.

They have capture filters and view filters, each with its own syntax. The
view filters seem easier for me to understand, so I just let it capture
everything and use the view filters to see what I want, like filtering on
HTTP to debug HTTP headers.

-Mike
 
Hi Mike,

Thanks for responding and for pointing out that pages were no longer
accessible - we recently did a code push which

invalidated those URLs. The URLs are now active again:

http://www1.zvents.com/events/test (page under ruby on rails)
http://www1.zvents.com/test.html (page outside of ruby on rails)

As for the HTTP headers, here's what Ethereal tells us for the page under
Ruby on Rails:

(http://www1.zvents.com/events/test)
(Ethereal doesn't seem to let you cut and paste, so I typed these in and
there might be typos):
IE6 Client Request HTTP headers:
GET /events/test HTTP/1.1
Accept: */*
Accept-Language: en-us
----
User-Agent: Mozilla/4.0 (compatible: MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
Host: www1.zvents.com
Connection: Keep-Alive

HTTP Headers in Server Response:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 14 Nov 2005 03:54:02 GMT
Content-Type: text/html; charset=utf-8
Set-Cookie:_session_id=blah; path=/
Cache-Control: no-cache
Server: lighttpd/1.4.3


Firefox Client Request HTTP headers:
GET /events/test HTTP/1.1
Host: www1.zvents.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png/*.*
Accept-Language: en-us,en;q=0.5
----
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0

Server Response:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 14 Nov 2005 04:03:08 GMT
Content-Type: text/html; charset=utf-8
Set-Cookie: _session_id=blah; path=/
Cache-Control: no-cache
Server: lighttpd/1.4.3

The only difference seems to be that Firefox sends "Cache-Control:
max-age=0" in the request. Note that the server

sends back "Cache-Control: no-cache" in the response. Thinking that the
server response Cache-Control header might

influence whether IE repopulates form values, I changed it's value (on this
page only) to "max-age=86400,private" in

the response, but there was no change in behavior (forms still not
repopulating in IE, but working fine in Firefox).


Here are the headers for the same page outside of Ruby on Rails
(http://www1.zvents.com/test.html)
IE6 Client Request:
GET /test.html HTTP/1.1
Accept: */*
Accept-Language: en-us
----
If-Modified-Since: Mon, 14 Nov 2005 03:50:27 GMT
If-None-Match: "-718824...."
User-Agent: Mozilla/4.0 (compatible: MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
Host: www1.zvents.com
Connection: Keep-alive

Server Response:
HTTP/1.1 304 Not Modified
Date: Mon, 14 Nov 2005 04:19:33
Content-Type: text/html
ETag: "-718824..."
Accept-Ranges: bytes
Last-Modified: Mon, 14 Nov 2005 03:50:27 GMT
Content-Length: 0
Server: lighttpd/1.4.3

Does that give you anything to go on? I had a theory that IE would only
repopulate pages with a .html extension, but that seems unlikely since each
page has "Content-Type: text/html" in the response headers - relying on the
actual extension seems unlikely.

Tyler
 
Tyler said:
As for the HTTP headers, here's what Ethereal tells us for the page under
Ruby on Rails:

(http://www1.zvents.com/events/test)
(Ethereal doesn't seem to let you cut and paste, so I typed these in and
there might be typos):
...
Does that give you anything to go on? I had a theory that IE would only
repopulate pages with a .html extension, but that seems unlikely since
each
page has "Content-Type: text/html" in the response headers - relying on
the
actual extension seems unlikely.
Click to expand...

Ouch! That's gotta hurt, typing in all those headers. :-)

It is odd that Ethereal doesn't have a copy function for the decoded packets
(they have it for the raw dump). But there is an export function with
several formats including plain text. So I captured separate sessions on the
good and bad pages, starting in a fresh IE instance each time, loading and
then reloading the page. I set the display filter to http and expanded the
Hypertext Transfer Protocol header in the middle pane. Then I did an export
to text format, selecting the Displayed button and the Packet Details: As
Displayed option.

After doing that for each page, I compared the two results in Araxis Merge
(http://www.araxis.com/). I edited out the uninteresting Ethernet/IP/TCP
headers and kept the HTTP stuff, then generated an HTML report of the diff:

http://mg.to/test/zvents-headers-diff.html

The report shows some other differences in the headers besides what you
mentioned. One that jumps out at me is the Last-Modified header in the good
version only. Also the good version has Content-Type:
application/octet-stream and a couple of other little differences.

If it's not a header difference, then as you mentioned it could just be the
different file extensions in the URLs (as shocking as that would be). It
would be an easy test to rig up one of the two test pages to match the URL
of the other one. Wouldn't it be funny if that's all it was and I led us
astray with all the header research! :-)

-Mike
 
Mike,

Great news! I finally got it to work and you were right - it was due to the
headers. I discovered that IE would not repopulate form values unless
certain headers were set correctly. The three headers I had to set to get
it working were:

ETag
Cache-Control
Last-Modified

By default, Ruby on Rails does not set these headers on responses. Now,
here's the gotcha. The form I was working with was embedded in an iframe
within the main page and it turns out that IE refused to repopulate this form
even when I had the headers set correctly for the HTTP connection serving the
iframe content. Try as I might, I just couldn't get it to work. I worked
around this problem by setting up hidden form values in the main page and
using javascript within the iframe to get the data from the main page form
fields. It's kinda ugly, but it works.

Now our users can happily hit the back button on IE and our AJAX calendars
will return to the view type and date that they were at when they left the
page. I'm very happy. Thanks for your help!

Tyler
 
Back
Top