Bug 28380

Created attachment 34954 [details] Test case to reproduce the bug (two HTML files, zipped). In a certain strange scenario, the name of a button included in the HTML will not be displayed and, instead, the name of another button from another, recent page is used instead. I've managed to simplify this to the contrived test case attached. Here's how to reproduce it: 1. Load testPage1.html in the browser. 2. Click the link to go to page two. 3. Notice that there is one submit button, labelled 'First Button from Page Two'. 4. Open testPage2.html in a text editor. 5. Comment out the section indicated as 'Page Two' and uncomment the section indicated as 'Page Three'. Save your changes. 6. Back in the browser, click the browser's Back button to go back to page one. 7. Empty the browser's cache. 8. Click the browser's Forward button to go to page two again. (Note: *Don't* click the 'Go to page two' link.) 9. The headings and text from page three are displayed, as expected, but the submit button is still labelled 'First Button from Page Two', rather than 'Second Button from Page Three' as indicated in the HTML. (As I said, this is a bit of a contrived example, since you have to manually change the content of the page and empty the browser's cache halfway through. The real-world scenario we're seeing this in is with a page in our Web app that has cache control etc. set up so that it won't be cached by the browser; the user loads this page, then clicks the Back button, and then their session times out before they click the Forward button again, so when the server receives the request for the (non-cached) page, it instead renders the log-in page for them. At this point, they get confused when the submit button for the log-in form does not say 'Log In', but rather whatever was the first submit button on the old page (for example, 'Delete Task'!). Steps 4, 5 and 7 in the above instructions are my simple equivalent of the cache-control headers and the session time-out in the real-world situation.) I think this might have some relationship to the previous WebKit bug 10541. My theory is that it's to do with form state being saved locally by the browser; because neither of the submit buttons in the example have 'name' attributes, there's no easy way for WebKit to distinguish between them, and so it 'restores' the state from the first form over the top of the second one. Speaking without having seen any of the code involved :-), would one simple fix here be to stop saving the 'value' attribute for submit buttons as part of the form state, since it isn't editable by the user anyway? From a Web developer's perspective, the easy workaround for this bug is to add name attributes to all submit buttons.