Bug 11078 - document.all.item(someString) doesn't work
Summary: document.all.item(someString) doesn't work
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://dnb.com/globalsignin/forgetpas...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-28 09:52 PDT by Jared Roussel
Modified: 2011-12-14 10:57 PST (History)
3 users (show)

See Also:


Attachments
Test item() by name (307 bytes, text/html)
2006-09-29 06:08 PDT, mitz
no flags Details
Make item() fall back to namedItem() (7.70 KB, patch)
2007-01-08 15:17 PST, mitz
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jared Roussel 2006-09-28 09:52:49 PDT
There are a few sites that I've noticed so far that won't post the form when the submit button is pressed using Safari. I have noticed three instances of this so far. One is on eBay when you want to add another category to your sell listing, one is during a session of an account I login to, but most importantly, a verifiable and specific one is at http://dnb.com/globalsignin/forgetpassword.asp. The submit button will just not post the form on Safari. I've noticed that all of the sites in these examples are ASP pages.
Comment 1 mitz 2006-09-29 06:05:56 PDT
The form in the URL fails to submit when the Submit button is clicked due to a JavaScript error. The root cause is that it uses document.all.item("name"). Firefox and Opera allow access by name using item() whereas WebKit allows it only using namedItem().

The form can be sumbitted by pressing Enter when the text field has focus. This obviously bypasses the Submitt button's onclick handler, and results in the same form loading again without any message (the behavior is the same in Firefox and WinIE as well).
Comment 2 mitz 2006-09-29 06:08:15 PDT
Created attachment 10834 [details]
Test item() by name
Comment 3 mitz 2007-01-08 15:17:42 PST
Created attachment 12313 [details]
Make item() fall back to namedItem()

This patches implements Firefox's behavior. IE apparently does not try to convert strings to numbers, making it fail the first case in the attached layout test.
Comment 4 Darin Adler 2007-01-08 20:19:45 PST
Comment on attachment 12313 [details]
Make item() fall back to namedItem()

r=me
Comment 5 Alexey Proskuryakov 2007-01-08 21:56:36 PST
Do we need a similar quirk in other item() methods (e.g., HTMLSelectElement::item()?)

+            return toJS(exec,coll.item(index));

Should have a space after a comma.
Comment 6 Alexey Proskuryakov 2007-01-09 09:55:46 PST
Comment on attachment 12313 [details]
Make item() fall back to namedItem()

Committed revision 18715.

Mitz has suggested leaving this bug open as a reminder to research the behavior of other item() methods. Clearing the review flag from a landed patch.
Comment 7 Alexey Proskuryakov 2007-01-11 21:42:24 PST
See also: http://ln.hixie.ch/?start=1161042744&count=1
Comment 8 Eric Seidel (no email) 2007-10-01 09:14:34 PDT
Hum... unfortunately leaving a bug open after landing the patch means that it appears in the "forgotten bugs" queue.  Perhaps there could be a new bug to cover any remaining issues in item() and this could be closed?
Comment 9 Alexey Proskuryakov 2010-06-11 16:33:52 PDT
Obviously, this bug didn't serve as a good reminder, but it's still wrong to have the quirk in only one version of item().
Comment 10 Alexey Proskuryakov 2011-12-14 10:57:02 PST
We now have a specific bug tracking the incorrectness of fallback, bug 74468.

Marking FIXED since keeping this bug open proved confusing, and didn't result in any action. Renaming to be clear about what was fixed.