Last Comment Bug 524423 - User property of a <form> element is not enumerable
: User property of a <form> element is not enumerable
Status: RESOLVED FIXED
[firebug-p2]
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla24
Assigned To: Andrea Marchesini [:baku]
:
: Andrew Overholt [:overholt]
Mentors:
Depends on: ParisBindings 622298 841442
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-26 00:35 PDT by Jan Honza Odvarko [:Honza]
Modified: 2013-12-03 05:21 PST (History)
13 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Jan Honza Odvarko [:Honza] 2009-10-26 00:35:46 PDT
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
Comment 1 Jan Honza Odvarko [:Honza] 2009-11-27 06:41:50 PST
Any chance to get this fixed? I believe that 3.7 could be the target.
Honza
Comment 2 John J. Barton 2009-12-16 16:59:59 PST
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.
Comment 3 Jan Honza Odvarko [:Honza] 2009-12-17 03:06:02 PST
> 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 Johnny Stenback (:jst, jst@mozilla.com) 2010-01-26 17:41:23 PST
Not blocking 1.9.3 on this. Does anyone know what the HTML5 spec says about this?
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2010-01-26 20:18:13 PST
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 Sebastian Zartner 2010-06-25 16:53:39 PDT
Still no progress in this issue?
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2010-06-25 18:32:42 PDT
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 Cameron McCormack (:heycam) 2010-10-12 01:38:39 PDT
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 Boris Zbarsky [:bz] (still a bit busy) 2010-10-12 06:28:07 PDT
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 Cameron McCormack (:heycam) 2010-10-13 14:24:51 PDT
(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 Boris Zbarsky [:bz] (still a bit busy) 2010-10-13 18:02:30 PDT
> 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 Cameron McCormack (:heycam) 2010-10-13 18:07:53 PDT
(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 Boris Zbarsky [:bz] (still a bit busy) 2010-10-13 19:07:23 PDT
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 Cameron McCormack (:heycam) 2011-05-25 17:01:31 PDT
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 Cameron McCormack (:heycam) 2011-06-17 22:44:36 PDT
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.
Comment 16 Sebastian Zartner [:sebo] 2012-10-30 03:12:42 PDT
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
Comment 17 Sebastian Zartner [:sebo] 2013-12-02 16:46:49 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2013-12-02 17:51:40 PST
Yeah, this got fixed in bug 841442.

Note You need to log in before you can comment on or make changes to this bug.