Bug 93518 – Submitting a form, then clicking back changes hidden input values.

• Status: UNCONFIRMED
• Component: Forms

[Frank Forte]

Submitting a form, then clicking back would change hidden input values.

I have three forms on a page, completely valid HTML5.  The third form has the following hidden inputs:
type="hidden" name="order_id" value="new"
type="hidden" name="order_type" value="up"

After submitting the form, then clicking back, the page source says (correctly) for the third form:
type="hidden" name="order_id" value="1"
type="hidden" name="order_type" value="up"

The above values are pre-populated server side so that they can edit the current order (as opposed to creating a duplicate order)


HOWEVER, the "inspect element"  (Google Chrome 21.0.1180.75 m) shows:
type="hidden" name="order_id" value="new"
type="hidden" name="order_type" value="new"

The value "new" for order type is completely unexpected in the third form, it should be "up" as the page source indicates.

Submitting the third form again makes my website throw an error because the form fields in the third form do not match the order type "new". (The order type should be "up"). This is how I found the bug.

Two things that went wrong:
1) the value of order_id is not being updated in the DOM... even though when I click "view source" it shows the correctly updated value.

2) order_type is getting a completely unexpected value

This bug went away when I changed the inputs to type="text" and added style="display:none"

[Frank Forte]

User Agent info:

Mozilla/5.0
Windows
NT
6.1
WOW64
AppleWebKit/537.1
KHTML,
like
Gecko
Chrome/21.0.1180.75
Safari/537.1

(In reply to comment #1)
> User Agent info:
> 
> Mozilla/5.0
> Windows
> NT
> 6.1
> WOW64
> AppleWebKit/537.1
> KHTML,
> like
> Gecko
> Chrome/21.0.1180.75
> Safari/537.1

Please add test cases(.html file)

[Stuart Morrison]

Created attachment 212456 [details]
Test Case

Can replicate behaviour with this simple html file when accessed via 
https with no-cache set.

You'll need to alter form target to point somewhere valid.

1) Submit form on page1.html with current values.   
   (POSTed values: input_h == '123', input_t == 'ABC')

2) Edit page1.html (set input_h = '456', input_t = 'DEF'.

3) Click 'back' in browser.

4) Submit page1.html 
   (POSTed values: input_h=='123', input_t=='DEF')


Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) 
AppleWebKit/536.26 (KHTML, like Gecko) 
Version/6.0 Mobile/10A403 Safari/8536.25

We noticed this because the behaviour breaks our on-line 
store when a customer goes 'back' on iPad. Have not seen the
issue on other browsers.

[Frank Forte]

my encounter was also over Https. 

Unfortunately Our Code Has Evolved And I Don't Have A Test Case Available.


Thanks for The Test Case Stuart.