566879 - [HTML5] HTML5 parser incorrect behavior with form controls

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P2)

Description

[Dricks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: 

If you have a form with input controls (checkbox, radiobuttons, textbox) and that you replace some of them using innerHTML in Javascript, the control's state coming from this innerHTML are not applied.

Reproducible: Always

Steps to Reproduce:
1. Test the give URL with Firefox 3.7a5 with html5 parser enabled
2. Put a value inside the textbox.
3. Click on a radio or on the checkbox
Actual Results:  
The value in the textbox is still there.
The clicked radio or checkbox is checked.

Expected Results:  
The textbox should be empty.
Only the radio1 radiobutton should be checked.


It works OK if you disable HTML5 parser (about:config -> html5.enable = false ).
or if you use a previous version of firefox.

Tested on Windows XP and on Ubuntu 10.04 with the latest builds of Firefox (20100519)

Comment 1

[Dricks]

Note :
If the controls aren't included in a FORM element, it works.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100519 Minefield/3.7a5pre

Comment 3

[Boris Zbarsky [:bzbarsky]]

Are we ending up doing state restoration here when we didn't use to before?

Comment 4

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Could be fallout from bug 562013.

Comment 5

[awesome89999]

I am a new Mozilla developer. I am thinking of working on this bug, but I need help to get started.

Can somebody please point me to the source code that would need to be changed?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

This depends on bug 569538, and after that is fixed form element handling
needs to be change if element is created in innerHTML.

Form elements are under content/html/content
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/

Comment 7

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Attachment: Fix without a test case

Comment 8

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Attachment: Fix with a bogus test case

This test case doesn't fail appropriately without the fix. Is it necessary to simulate user input to make sure the intermediate form state gets saved?

Comment 9

[Hubert FONGARNAND]

Your patch did'nt apply cleanly on trunk 

hfongarnand@hfongarnand-desktop:~/Programmes/mozilla-central$ cat ./formrestore.patch | patch -p1
patching file content/html/content/src/nsHTMLInputElement.cpp
Hunk #2 succeeded at 134 (offset 2 lines).
Hunk #3 FAILED at 509.
Hunk #4 succeeded at 2955 (offset 119 lines).
1 out of 4 hunks FAILED -- saving rejects to file content/html/content/src/nsHTMLInputElement.cpp.rej
patching file content/html/content/src/nsHTMLSelectElement.cpp
patching file content/html/content/src/nsHTMLSelectElement.h
patching file content/html/content/src/nsHTMLTextAreaElement.cpp
Hunk #1 succeeded at 76 with fuzz 2.
Hunk #2 succeeded at 205 with fuzz 1 (offset 22 lines).
Hunk #3 FAILED at 230.
Hunk #4 succeeded at 679 (offset 15 lines).
1 out of 4 hunks FAILED -- saving rejects to file content/html/content/src/nsHTMLTextAreaElement.cpp.rej

Comment 10

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Attachment: Fix with a test case

(In reply to comment #9)
> Your patch did'nt apply cleanly on trunk 

Conflicting stuff landed. Here's the patch rebased to tip.

Comment 11

[Hubert FONGARNAND]

ok, tested on my ubuntu box...

it seem's to fix the problem!

Comment 12

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Comment on attachment 450095 [details] [diff] [review]
Fix with a test case

It seems the test tests the right thing after all, and I previously mistested the test...

Comment 13

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Thanks. Pushed http://hg.mozilla.org/mozilla-central/rev/a1f73f137c41