RESOLVED INVALID 18472
JavaScript cached, window.onload not fired when returning to the form via back button 
https://bugs.webkit.org/show_bug.cgi?id=18472
Summary JavaScript cached, window.onload not fired when returning to the form via ba...
Dushan Hanuska
Reported 2008-04-13 22:42:26 PDT
It seems that if I submit a form and then return to it via browser's back button: - JavaScript variables are not reset, i.e. they are set with their last values - window.onload does not fire This behavior is new. I tested our pages in Safari 3.0.4 and it all worked fine. After upgrading to Safari 3.1 the above described behavior occurred. The easiest way to test it is with the following HTML file: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <body> <form action="http://www.atlassian.com/" id="jiraform" name="jiraform"> <input type="text" name="abc"> <input type="submit"> </form> <script type="text/javascript" charset="utf-8"> (function() { var disableFormSubmit = function() { var f = document.jiraform; f.onsubmit = function () { if (f.submitted) { return false; } f.submitted = true; return true; }; }; if (window.onload) { var oldOnLoad = window.onload; window.onload = new function () { oldOnLoad(); document.jiraform.submitted = false; disableFormSubmit(); }; } else { window.onload = new function () { document.jiraform.submitted = false; disableFormSubmit(); }; } })(); </script> </body> </html> Steps to reproduce the problem: - load the file in the browser - enter some text into the input field - click Submit button - after navigating to the next page, click the browser's back button - notice that form is pre-populated with the originally submitted value, Submit button no longer works. This code is similar to our code in JIRA. The purpose of this code is to set a 'submitted' attribute on the form object to prevent accidental re-submitting of the form (e.g. user clicks the Submit button twice). The reason why this does not work is: - originally non-existent variable document.jiraform.submitted now exists and equals to true - window.onload was not fired Cheers, Dushan
Attachments
Add attachment proposed patch, testcase, etc.
Dushan Hanuska
Comment 1 2008-05-12 01:44:27 PDT
Note that serving the page with the following doesn't help: Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: -1
Jed Wesley-Smith
Comment 2 2008-11-26 15:05:20 PST
Safari 3.1.2 does not seem to have the problem.
Alexey Proskuryakov
Comment 3 2008-11-27 07:30:01 PST
Could you please explain why this is a problem? I'm not an expert, but it sounds like expected behavior for back/forward cache.
Jed Wesley-Smith
Comment 4 2008-11-30 18:06:24 PST
well, javascript variables that are otherwise scoped to a single page view become cached, and the window.onload() is not triggered so you cannot manually remove/reset them, nor do the usual cache control headers help. Note however, that this does not happen with the latest Safari 3.1.* builds so this is likely related to a separate (fixed) bug.
Alexey Proskuryakov
Comment 5 2008-12-03 05:38:16 PST
The test from bug description fails for me in both Safari 3.2.1 and Firefox 3.0.1. So, I don't think that the behavior is incorrect. The test "passes" in nightly builds indeed - but that's only due to a new and worse bug: form onsubmit handler is not called at all the second time. I've filed bug 22625 to track this.
Alexey Proskuryakov
Comment 6 2009-03-02 03:52:33 PST
This is correct behavior - reviving a page from back/forward cache is not the same as loading it. The only events that should be fired are pageshow/pagehide (but WebKit doesn't support them yet). If you want to prevent a page from ever going into back/forward cache, you can install an unload event handler. Besides, I don't think that you should need any of this code: WebKit has built-in double form submission prevention.
Note You need to log in before you can comment on or make changes to this bug.