Closed
Bug 524423
Opened 15 years ago
Closed 11 years ago
User property of a <form> element is not enumerable
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla24
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: Honza, Assigned: baku)
References
(Depends on 1 open bug)
Details
(Whiteboard: [firebug-p2])
If I create a <form> element and set a new property on it, it's not visible when enumerating properties. As far as I know it's because <form> elements implement an enumerate hook to access form fields. Expected Result: Even if creating user properties on <form> elements isn't a recommended technique, there should be a way how to bypass the hook so, user properties can be enumerable and displayed by tools like Firebug. Example of the bug: var form= document.createElement('form'); form.myProp = {ID:'test', Value:'someValue'}; // Following cycle doesn't see the "myProp" property for (var p in form) { // ... } Related Firebug bug: http://code.google.com/p/fbug/issues/detail?id=642 Related Discussions: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/d7417daf8ae62ebd?hl=en http://groups.google.cz/group/mozilla.dev.tech.js-engine/browse_thread/thread/11b6bfd74887472f# Honza
Reporter | ||
Updated•15 years ago
|
Whiteboard: [firebug-p2]
Updated•15 years ago
|
Assignee: ashuk → nobody
Component: Java APIs for DOM → DOM
QA Contact: dom-apis → general
Reporter | ||
Comment 1•15 years ago
|
||
Any chance to get this fixed? I believe that 3.7 could be the target. Honza
Comment 2•15 years ago
|
||
Another report: http://code.google.com/p/fbug/issues/detail?id=2579 test case online http://fbug.googlecode.com/svn/tests/issues/2579/MissingProperty.html use with Firebug 1.4.5 or 1.5, say http://getfirebug.com/releases/firebug/1.5X/firebug-1.5X.0b6.xpi I don't believe this is related to Firebug directly, its the enumeration that fails.
Updated•15 years ago
|
blocking2.0: --- → ?
Reporter | ||
Comment 3•15 years ago
|
||
> I don't believe this is related to Firebug directly, its the enumeration that
> fails.
yes, see also a comment from Boris:
"More to the point, forms have an enumerate hook which effectively
enumerates form.elements in order, as far as I can tell. I wonder
whether this is needed for web compat... "
Honza
Comment 4•14 years ago
|
||
Not blocking 1.9.3 on this. Does anyone know what the HTML5 spec says about this?
blocking2.0: ? → -
Comment 5•14 years ago
|
||
I raised this in an HTML5 thread at some point. The spec _seems_ to say to enumerate the numbered properties of the form in addition to the user-set stuff. Or something. It's not very clear.
Comment 6•14 years ago
|
||
Still no progress in this issue?
Comment 7•14 years ago
|
||
This is blocked on a spec clarification, last I checked. So if you want progress, get the HTML WG or WHAT WG to pay attention to the issue...
Comment 8•14 years ago
|
||
Boris, could you point me to the part of HTML5 that requires the non-standard enumeration behaviour? We should try to remove that in favour of the correct enumeration falling out of the way properties get set on the object, if possible.
Comment 9•14 years ago
|
||
It looks like it doesn't anymore, which is not web-compatible. In particular, for the named properties enumeration order needs to be index order, no? Not sure about the indexed ones, since Gecko doesn't implement those.
Comment 10•14 years ago
|
||
(In reply to comment #9) > In particular, for the named properties enumeration order needs to be index > order, no? No idea. Does any spec currently specify property enumeration order? I had thought ES5 was going to do so, but apparently not. (Although it does require consistency in enumeration order between for..in, Object.keys(), etc.) Is enumeration order something Web IDL should specify then?
Comment 11•14 years ago
|
||
> Does any spec currently specify property enumeration order? No (though Harmony might), but de-facto it needs to be property addition order. Except for arrays. And forms. And so forth. > Is enumeration order something Web IDL should specify then? In cases when it doesn't match property addition order, presumably yes.
Comment 12•14 years ago
|
||
(In reply to comment #11) > No (though Harmony might), but de-facto it needs to be property addition order. > Except for arrays. And forms. And so forth. If you know of (or can supply me with) a list of objects that require non-standard property enumeration order that'd be helpful! Or a way to find them out without my having to test every DOM object. > > Is enumeration order something Web IDL should specify then? > > In cases when it doesn't match property addition order, presumably yes. Presumably also for cases where it does match property addition order, if this isn't documented anywhere currently.
Comment 13•14 years ago
|
||
Hmm. The custom enumerators we have (using their html5-ish names are): WindowProxy (enumerates the Window) HTMLFormElement Storage (enumerates keys in some order; not sure which order) That seems to be it. Oh, probably CanvasPixelArray too. JS array enumeration per se is not really the province of webidl.
Comment 14•13 years ago
|
||
I added to Web IDL a section that defines property enumeration for objects with index/name getters. Index properties are enumerated first, in numerical order. Then name properties, in whatever order is given by the spec that defines the interface. And that's it. So user defined properties on an HTMLFormElement object would never get enumerated. You would of course be able to use Object.getOwnPropertyNames() to get the names of all the properties on the object, and then to use Object.getOwnPropertyDescriptor() to determine if it's an enumerable property.
Comment 15•13 years ago
|
||
I did some more (correct) testing: http://www.w3.org/mid/20110618052618.GA30408@wok.mcc.id.au I now think we should enumerate these user defined properties on HTMLFormElement.
Updated•13 years ago
|
OS: Windows Vista → All
Hardware: x86 → All
Version: unspecified → Trunk
Comment 16•12 years ago
|
||
This issue was already reported to the Firebug team in 2008! Also all the other important browsers do not have this issue. Tested in Chrome 22, IE 9, Opera 12.02 and Safari 5.1.7. So is there any progress on this? Sebastian
Updated•12 years ago
|
Depends on: ParisBindings
Comment 17•11 years ago
|
||
This seems to be fixed in current versions of Firefox. I.e. in Firefox 25.0.1 I can see the "myProp" of the test case. So this bug can finally be closed. Sebastian
Comment 18•11 years ago
|
||
Yeah, this got fixed in bug 841442.
Updated•11 years ago
|
Flags: in-testsuite?
Updated•11 years ago
|
Assignee: nobody → amarchesini
Target Milestone: --- → mozilla24
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•