Bug 7967

Summary: Quirksmode: Cannot assign new properties to the object holding form elements sharing the same name
Product: WebKit Reporter: Marco Wise <marco.wise>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: adele, ahmad.saleem792, ap, bfulgham, ian, marco.wise, rniwa
Priority: P2 Keywords: InRadar
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Bug Depends on:    
Bug Blocks: 9610    
Attachments:
Description Flags
Simplified test case none

Marco Wise
Reported 2006-03-24 15:15:23 PST
It looks like IE and Firefox create a Nodelist to store multiple form inputs that share the same name. They allow for properties of this data structure to be set and retrieved. Safari (and Konqueror) seem to use something different (probably a DOMNamedNodesCollection?) that cannot be assigned new properties (adding properties fails silently). This problem was encountered when using CGI::FormBuilder to build forms with multiple submit buttons. CGI::FormBuilder's strategy is for these buttons to share the same name (_submit) and their onclick event handler to set _submit.value to the value of the button clicked. This value is retrievable in IE and Firefox, but not Safari and Konqueror. You can see the behaviour by going to: http://www.formbuilder.org/ex/multiple_submits.pl The validation code runs through even if you hit the cancel or delete buttons.
Attachments
Simplified test case (878 bytes, text/html)
2006-03-24 15:16 PST, Marco Wise 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Marco Wise
Comment 1 2006-03-24 15:16:13 PST
Created attachment 7289 [details] Simplified test case
Marco Wise
Comment 2 2006-03-27 12:19:27 PST
It does look like the class used for items with the same name is a DOMNamedNodesCollection, defined in kjs_dom.h. From Darin: "Looking at DOMNamedNodesCollection::getOwnPropertySlot, it looks like it supports length, indexing by number, and indexing by ID." Should it also support setting and getting other properties as a Nodelist in Firefox/IE?
Mark Rowe (bdash)
Comment 3 2008-02-05 12:50:18 PST
Comments on IRC suggest this also affects NodeList.
Mark Rowe (bdash)
Comment 4 2008-02-05 12:52:34 PST
<rdar://problem/5725722>
Maciej Stachowiak
Comment 5 2008-02-05 12:59:32 PST
I think the issue here is that we create a new collection object every time when a script requests the collection. Setting and getting properties works, but if you re-get the collection you are actually getting a different object.
Alexey Proskuryakov
Comment 6 2009-01-02 00:07:59 PST
*** Bug 9278 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 7 2009-01-02 00:11:04 PST
Bug 9278 has a test reduced from a Quirksmode report for accessing form element collections in a slightly different way via HTMLFormElement.elements.
Ahmad Saleem
Comment 8 2022-08-09 09:33:39 PDT
I am unable to reproduce this bug with "Firefox" behavior described in Safari 15.6 on macOS 12.5 because now all browsers return "empty" dialog box upon clicking buttons on the attached test cases. Since all browsers (Chrome Canary 106, Firefox Nightly 105 and Safari 15.6 on macOS 12.5) are aligned and just show "" / undefined / empty dialog boxes on clicking the buttons rather than as mentioned of showing "One" or "Two" of value, I think this can be marked as "RESOLVED INVALID" because Firefox changed the behavior here where previously it used to show value of button clicked. Please reopen if I am incorrect. Thanks!
Note You need to log in before you can comment on or make changes to this bug.