bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

[HTML5] HTML5 parser incorrect behavior with form controls




HTML: Parser
8 years ago
8 years ago


(Reporter: Dricks, Assigned: hsivonen)




Firefox Tracking Flags

(blocking2.0 final+)




(1 attachment, 2 obsolete attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: 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)


8 years ago
Version: unspecified → Trunk

Comment 1

8 years ago
Note :
If the controls aren't included in a FORM element, it works.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100519 Minefield/3.7a5pre
Are we ending up doing state restoration here when we didn't use to before?
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression

Comment 4

8 years ago
Could be fallout from bug 562013.
Summary: HTML5 parser incorrect behavior with form controls → [HTML5] HTML5 parser incorrect behavior with form controls


8 years ago
blocking2.0: ? → final+

Comment 5

8 years ago
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?
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


8 years ago
Priority: -- → P2

Comment 7

8 years ago
Created attachment 449856 [details] [diff] [review]
Fix without a test case
Assignee: nobody → hsivonen

Comment 8

8 years ago
Created attachment 449858 [details] [diff] [review]
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?
Attachment #449856 - Attachment is obsolete: true

Comment 9

8 years ago
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

8 years ago
Created attachment 450095 [details] [diff] [review]
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.
Attachment #449858 - Attachment is obsolete: true

Comment 11

8 years ago
ok, tested on my ubuntu box...

it seem's to fix the problem!

Comment 12

8 years ago
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...
Attachment #450095 - Attachment description: Fix with a bogus test case, rebased to tip → Fix with a test case
Attachment #450095 - Flags: review?(Olli.Pettay)

Comment 13

8 years ago
Thanks. Pushed http://hg.mozilla.org/mozilla-central/rev/a1f73f137c41
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.