Bug 26241

Overview Description: WebKit save/restore value of a input element from WebCore::HistoryItem. But this behavior seems strange at non-bfcached page. Steps to Reproduce: 1) Create a simple "counter" app. that returns the following HTML. And #{count} is incremented by each access. <form method="get" action="/foo"> #{count} <input type="hidden" name="count" value="#{count}"/> <input type="submit" /> </form> <iframe src="http://webkit.org/"></iframe> 2) Access the page and press "Submit" button. New page is "/foo?count=1". 3) Press browser's "Back" button. WebKit requests the page agin because bfcache is disabled by the iframe. 4) The application *increments counter* and returns HTML again. 5) Press "Submit" again. Expected Results: New page is should be "/foo?count=2" because WebKit requests the page and the server returns new HTML. Actual Results: New page is "/foo?count=1". Because WebCore::FrameLoader::restoreDocumentState and WebCore::HTMLInputElement::restoreState replaced value of input elements by the old (saved) values. This behavior sometimes useful. When user input long (or complex) value, WebKit should save the value and user can notice when "restore" is wrong. But I think, WebKit don't need to save/restore value of <input type="hidden" .../> because user don't input the value and user can't notice WebKit's "restore". Index: WebCore/html/HTMLInputElement.cpp =================================================================== --- WebCore/html/HTMLInputElement.cpp (revision 44489) +++ WebCore/html/HTMLInputElement.cpp (working copy) @@ -422,7 +422,6 @@ case BUTTON: case EMAIL: case FILE: - case HIDDEN: case IMAGE: case ISINDEX: case NUMBER: @@ -440,6 +439,7 @@ setChecked(state == "on"); break; case PASSWORD: + case HIDDEN: break; } }