28380 2009-08-16 23:13:23 -0700 Button names replaced with other button names 2010-05-23 20:23:41 -0700 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) Mac (Intel) OS X 10.5 RESOLVED DUPLICATE 26241 P2 Major --- 0 david-webkit webkit-unassigned tkent oldest_to_newest 140668 0 34954 david-webkit 2009-08-16 23:13:23 -0700 Created attachment 34954 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. 140669 1 david-webkit 2009-08-16 23:15:55 -0700 I should add: I've been able to reproduce this in Safari 3 (3.2.3 (5525.28.3)), Safari 4 (Version 4.0.3 (5531.9) and OmniWeb 5.10 (sneakypeek v6.22.8.0.116891), as well as the latest WebKit nightly build (r47291). 221064 2 tkent 2010-05-05 05:24:39 -0700 I think it was fixed by r57013. *** This bug has been marked as a duplicate of bug 26241 *** 229585 3 david-webkit 2010-05-23 20:23:41 -0700 Just to confirm, I've tested this in a recent build (59711) and all looks good. Thank you! 34954 2009-08-16 23:13:23 -0700 2009-08-16 23:13:23 -0700 Test case to reproduce the bug (two HTML files, zipped). buttonNameTest.zip application/octet-stream 827 david-webkit UEsDBBQAAAAIAEF4ETt2hHGFtAAAAPQAAAAOABUAdGVzdFBhZ2UxLmh0bWxVVAkAA0rkiEqf9IhK VXgEAPUBFABNjcsKwjAQRdfmK8bszVjtSmIWtkUFH0Ui4jLS2BZqI+1A8O81tAtnM9y5hzNymp4T fc8z2OnjAfLr5rBPgM8Qb8sEMdXpUMRiHoHuTNvXVLvWNIjZiTMYh1dE7xWi9174pXBdifqCFb2a GBvneisKKrhiMpzCsqZQbCKppsaq3JQWzq2VOGQmcQDkwxWfgEd/zC8waaDq7HPNyfYUqoUIZq62 DsjBO8DknUSjxM82anD4/gVQSwMEFAAAAAgAdoERO93JZ4JdAQAABQMAAA4AFQB0ZXN0UGFnZTIu aHRtbFVUCQADn/SISrr0iEpVeAQA9QEUAKWSy07DMBBF1/grpl7BIjF9rKiTRV8CVGhEgxBLt3Gb SE5cxROi/j1x3RcgQAhvrJk7ujNzbN4azYbxazSG2/hhCtHzYHo3BOox9tIdMjaKR07o+ddtiEtR mAwzXQjF2PiREtgfmiJubhir69qvu74u1yx+YinmqseU1kb6CSY0JNymQkIIb3keRGItIa41eN4u l0qRhOSCY4ZKhgeVMxcTzlwBX+hka73aZzVNQPhKlzmIpZ0woCgNWr3r26YUcompTgIazeYxBV2Y apFnGNBSYlUWsBLKyH4zo92Hp52jN0wa16ZBZy9lxaZCwO1GBtR5UFgqYUxAE7kSlcJBhagLCm9C VU3RJCsNgkvCqtT5cXEKzK5lx7a322sPZ1wknwGdU0tLKb9BZqXfobmqP2I7PvgJn0l1fT+3jC6v +vAzTNvz3zjncqkbNl95WvcPRE9ITzB3IxxwMvcd3wFQSwECFwMUAAAACABBeBE7doRxhbQAAAD0 AAAADgANAAAAAAABAAAApIEAAAAAdGVzdFBhZ2UxLmh0bWxVVAUAA0rkiEpVeAAAUEsBAhcDFAAA AAgAdoERO93JZ4JdAQAABQMAAA4ADQAAAAAAAQAAAKSB9QAAAHRlc3RQYWdlMi5odG1sVVQFAAOf 9IhKVXgAAFBLBQYAAAAAAgACAJIAAACTAgAAAAA=