[Webkit-unassigned] [Bug 28380] New: Button names replaced with other button names

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28380

           Summary: Button names replaced with other button names
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Major
          Priority: P2
         Component: Forms
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: david-webkit at shepherdson.name


Created an attachment (id=34954)
 --> (https://bugs.webkit.org/attachment.cgi?id=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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.