We have a ten-page webform (survey) that takes about 15 minutes to fill out. On IE, when the user is past page 2 then clicks the back button on the browser (not the form buttons) IE displays a "Webpage has expired" with a blank page. The user cannot go forward again and so they lose all their webform data they entered.
This was found on IE 8/9, webform 6.x-3.11. Forward
Other sites (non-Drupal) have suggested that I will need to use this code:
ini_set('session.cache_limiter', 'private');
I put this in a webform template, but this didn't seem to work and not sure if it is safe for Drupal.
Has anyone else run into this problem on a multi-page webform? Any thoughts on how I can solve this?
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | browser_back_button_on-1219548-10.patch | 1.22 KB | BarisW |
| #7 | browser_back_button_on-1219548-7.patch | 520 bytes | BarisW |
Comments
Comment #1
quicksketchConsidering installing http://drupal.org/project/dirtyforms. Webform is currently designed to only work with POST submissions, so use of the browser back button will almost always cause *some* data loss, but in the case of IE, it's a bit more pronounced because it doesn't prompt the user to re-submit their POST data like other browsers will. This may be solvable through #335480: Set separate URL for each page of Multi-Page Forms (Funnel Tracking), but it essentially involves rewriting the form handling in Webform.
Comment #2
gregstout commentedInteresting module, but it looks like that will not help retain information but rather will let the user know when they are leaving the page that they might lose some information. Given this is a multi-page form that all reside on the same URL, it seems this will not help. Also, that has some additional dependencies.
There is so much information being recorded in this form that I am a little worried of hitting the POST limit.
The separate URL for each page, might be interesting - at least with a &page parameter in the URL. I will look into that. I am not wanting to modify the webform module, but maybe I can hook into it or do some minor tweaking.
Comment #3
quicksketchThe POST limit won't be a problem unless you have so much information on a single page. Webform doesn't use POST to store information from previous pages that have already been completed. In any case, the normal POST limit is usually MB in size, I doubt the user would surpass that unless you've added a file upload field.
Comment #4
gregstout commentedOk, I was able to solve this using by creating copying the webform-form.tpl.php file into our theme directory then adding this line of code to the top of it:
header("Cache-Control: private");We no longer have this error on the page when the users uses the back/forward browser buttons.
Comment #5
ArieKanarie commented@gregstout: This helped for me. Thanks! Just add
header("Cache-Control: private");
to the webform-form.tpl.php file.
Comment #6
BarisW commentedThis is an issue for all IE users and this can be fixed in Webform out of the box easily. I will add a patch to do so.
Comment #7
BarisW commentedHere's a patch that implements this. I've placed the code in
_webform_defaults_pagebreak()since that is the only function in the pagebreak component that is called on every pagebreak page, even the first page.This simple header removes the annoying warning that all IE users get when they press the Back button on their browser about that they have to re-submit their POST data.
Please review.
Comment #8
danchadwick commentedAssume this works as desired, I see two issues with the patch:
1) We should use drupal_add_http_header(), right?
2) This isn't the right place to do this. It would add this header on every page that loads the defaults for page_breaks. It should be used when rendering the page break, or possibly in webform_client_form. They may also be issues with the preview page.
And last, have we created any issues with reverse proxy servers and anonymous users submitting multi-page webforms?
Comment #9
danchadwick commentedComment #10
BarisW commentedHi Dan,
thanks for the review. I've added the script to webform_client_form() and used drupal_add_http_header().
I'm afraid I cannot answer your last question. Maybe someone else can?
Comment #11
danchadwick commentedI don't really see fixing IE oddities in webform. If this were an issue of sufficient importance, it would be fixed in the Drupal form API. I think this issue is best closed. Anyone can adjust their theme or write a module as described here.