Don't restore form values on tab restore
A part of my website uses a lot of forms on a single page. On the page, you can filter the items (each item has his own form) and alter them. A single entry looks like this: [name] [select for status] [other select]. Other significant things are that the document has a expire date in 1981 (to enforce an always up to date page) and that changing the value in the select results in triggering an AJAX function.
This works perfectly, except for a single thing. When filtering for status id 1, you get a few item's in return. Let's say that the result of the filter are 5 entry's. I change entry #2's status, thus triggering an AJAX function. this works great, but here's the problem: When closing the tab and re-opening using tab restore, the values of the select become messed-up.
Because of the enforcement of an always fresh copy of the page, the browser will fetch a new copy of the page. Entry #2 has now disappeared (I'll keep calling it that, even tough it has disappeared due to the filter). Now here's the problem: Firefox tries to restore the select's value. Entry #3's status has now the same status of entry #2, #4 has #3's status and so on.
I've managed to fix this on other browsers (Chrome, IE) with this little piece of jQuery: $(document).ready(function() { $("form[class^='startingformname']").each(function() { this.reset(); }) }); This works perfectly, except for Firefox, which seems to ignore the reset call...
As this text is rather long, I'll keep my question short: How do you prevent Firefox from restoring the values of the form (preferably: keep them on the selected item given in the HTML)? The user now always gets a fresh copy of the page, and Firefox tries to restore the old values on that page, even if the HTML has changed.
Solution choisie
I think your two choices are:
(1) prevent Firefox from caching the page, or
(2) use a different event to trigger your reset function
If I understand correctly, the jQuery $(document).ready() function fires on the DOMContentLoaded event (or equivalent, if not supported by the browser). If the tab is cached in its "fast back-forward cache," Firefox may not fire this event when the user returns to the tab, just as Firefox does not always fire the load event in such cases.
Check out the pageshow event described in the following article and see whether you can use that to trigger your reset function in Firefox: https://developer.mozilla.org/docs/Using_Firefox_1.5_caching
Does that make sense?
Lire cette réponse dans son contexte 👍 0Toutes les réponses (9)
Solution choisie
I think your two choices are:
(1) prevent Firefox from caching the page, or
(2) use a different event to trigger your reset function
If I understand correctly, the jQuery $(document).ready() function fires on the DOMContentLoaded event (or equivalent, if not supported by the browser). If the tab is cached in its "fast back-forward cache," Firefox may not fire this event when the user returns to the tab, just as Firefox does not always fire the load event in such cases.
Check out the pageshow event described in the following article and see whether you can use that to trigger your reset function in Firefox: https://developer.mozilla.org/docs/Using_Firefox_1.5_caching
Does that make sense?
That seems logical, but it is inconsistent with the other browsers.
I've tried to use the pageshow event by adding this: indow.addEventListener('pageshow', resetUserForms, false);
Now, the Tab reload goes as follows: 1. User restores tab 2. Firefox changes the values of the selects, triggering the onChange functions. 3. the pageshow event fires 4. The onChange function (AJAX) is done, changing the shown values back to the incorrect one's (This is to be expected, as that's part of the functionality of this particular function)
So, I suppose that I need to look for an event which fires before Firefox makes the changes to the forms. I'm looking for one, but I can't seem to find one. Any tips on this?
Sounds messy. In that case I would try one of the things that prevents Firefox from caching the page.
The problem isn't that Firefox caches the page, but it caches the select values. (The page isn't cached due to Cache-Control in the HTTP headers). When Firefox reopenes the page after you've closed it, it fetches a new, fresh copy of the page. The problem is: those two pages aren't the same...
Entry #2 would disappear in the sample, and Firefox makes the rest of the forms a big mess...
I'ld rather need a solution to prevent Firefox from caching form data, even if the page is restored.
You can reload web page(s) and bypass the cache to refresh possibly outdated or corrupted files.
- Hold down the Shift key and left-click the Reload button
- Press "Ctrl + F5" or press "Ctrl + Shift + R" (Windows,Linux)
- Press "Command + Shift + R" (Mac)
You can also consider to work in a Private Browsing mode window.
Unfortunately, that wouldn't work either. Firefox has already triggered the onChange function by then, and the AJAX would've updated the status in the database, making the values permanently wrong...
The thing is: The user wouldn't need to refresh the page, and the browser shouldn't restore the values of the forms.
The biggest problem, is that Firefox restores the values, even if the page is different. I just need a way to prevent Firefox from restoring the old values, as the new page is already up-to-date.
Edit: I just realized that tab restore works differently than Back. So please disregard this example.
But if you reload the page clearing the cache Ctrl+Shift+r, do the form fields revert to their original "as served" values? That's the typical behavior.
Here is a comparison of identical forms, the only difference is that the "B" version sets cache-control:no-store in the headers. The expected behavior is that you can submit the form on the "A" page and go back and see the modified values, but when you submit the form on the "B" page and go back the form should have only its default values.
Modifié le par jscher2000 - Support Volunteer
Can you post a demo page? I can't seem to get the field values into the wrong place in this test page when I add a new <input type="text"> to the DOM:
But your original post suggests that you might be adding an entire <form> which might behave differently than adding a field to a form.
Also, make sure to test in Firefox 23 as this is reminding me of a bug in an earlier version of Firefox that hopefully was fixed by now.
Modifié le par jscher2000 - Support Volunteer
Well, I've found the problem now... The problem was that each select field has his own id. Normally, this would be unique, but due to a stupid reason, we used "uid" plus an incremental number, causing the select ID's to overlap and Firefox to start thinking that the forms were the same... Oops!
Thank you for your help. I found this due to that you asked for a demo page. The other helpful thing was the explanation about the DOMContentLoaded event. I've learned something new today :)
I'll mark your first answer as the solution, as that was the most informative/helpful one from my perspective. Again, thank you! :)