Bug 7967 - Quirksmode: Cannot assign new properties to the object holding form elements sharing the same name
Summary: Quirksmode: Cannot assign new properties to the object holding form elements ...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 9278 (view as bug list)
Depends on:
Blocks: 9610
  Show dependency treegraph
 
Reported: 2006-03-24 15:15 PST by Marco Wise
Modified: 2022-08-09 09:33 PDT (History)
7 users (show)

See Also:


Attachments
Simplified test case (878 bytes, text/html)
2006-03-24 15:16 PST, Marco Wise
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Wise 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.
Comment 1 Marco Wise 2006-03-24 15:16:13 PST
Created attachment 7289 [details]
Simplified test case
Comment 2 Marco Wise 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?
Comment 3 Mark Rowe (bdash) 2008-02-05 12:50:18 PST
Comments on IRC suggest this also affects NodeList.
Comment 4 Mark Rowe (bdash) 2008-02-05 12:52:34 PST
<rdar://problem/5725722>
Comment 5 Maciej Stachowiak 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.
Comment 6 Alexey Proskuryakov 2009-01-02 00:07:59 PST
*** Bug 9278 has been marked as a duplicate of this bug. ***
Comment 7 Alexey Proskuryakov 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.
Comment 8 Ahmad Saleem 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!