User property of a <form> element is not enumerable

RESOLVED FIXED in mozilla24

Status

()

Core
DOM
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Honza, Assigned: baku)

Tracking

(Depends on: 1 bug)

Trunk
mozilla24
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [firebug-p2])

(Reporter)

Description

8 years ago
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

8 years ago
Whiteboard: [firebug-p2]

Updated

8 years ago
Assignee: ashuk → nobody
Component: Java APIs for DOM → DOM
QA Contact: dom-apis → general
(Reporter)

Comment 1

8 years ago
Any chance to get this fixed? I believe that 3.7 could be the target.
Honza

Comment 2

8 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.
blocking2.0: --- → ?
(Reporter)

Comment 3

8 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
Not blocking 1.9.3 on this. Does anyone know what the HTML5 spec says about this?
blocking2.0: ? → -
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

7 years ago
Still no progress in this issue?
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...
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.
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.
(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?
> 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.
(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.
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.
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.
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.
Depends on: 622298
OS: Windows Vista → All
Hardware: x86 → All
Version: unspecified → Trunk
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
Depends on: 580070
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
Yeah, this got fixed in bug 841442.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Depends on: 841442
Resolution: --- → FIXED
Flags: in-testsuite?
Assignee: nobody → amarchesini
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.