Closed Bug 684696 Opened 13 years ago Closed 10 years ago

Event objects prototype chain and properties are messy

Categories

(Core :: DOM: Events, defect)

6 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bruant.d, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: DUPEME)

I am writing little JavaScript object visualization tool (https://github.com/DavidBruant/ObjectViz) using ES5 Object.* methods. What is visualized is the object (top left), then its prototype, then its prototype, etc. At http://davidbruant.github.com/ObjectViz/ one can find the visualization of the global object. When clicking (anywhere on the document), the visualized object becomes the MouseEvent object created during the click event. On Firefox, one can see 5 objects. The first one has no property, then 3 prototype objects which all look pretty much the same with what appears to be some duplication (each of the 3 have a "bubbles", "type", "target", etc. property). A lot of constants are duplicated as well. Then, there is Object.prototype. White circle around most properties are getter/setter pairs. On Chrome, things are more clear. Things that refer to the current event are at the based object. Methods that should be inherited are at the 4th object (Event.prototype, I'd guess). There is no getter/setter pair (which makes a lot of sense). There is no duplication of constants. There is no standard as far as I know defining this. WebIDL, maybe? Regardless, I don't know if Chrome's organization is perfect but it looks much better and cleaner. I think Firefox should work at least toward not duplicating properties along the prototype chain.
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → 6 Branch
WedIDL is the relevant spec, yes. I find the visualization rather unclear; I think a more linear view would be helpful.
WebIDL defines properties as being getter/setter pairs on the relevant prototype. XPConnect flattens all properties from the prototype chain onto most-derived prototypes. This is not specific to event objects; it happens for everything. There's an existing bug report on that, of which this looks like a duplicate.
Whiteboard: DUPEME
(In reply to Ms2ger from comment #1) > WedIDL is the relevant spec, yes. I find the visualization rather unclear; I > think a more linear view would be helpful. I accept suggestions, Github issues and pull requests ;-) What do you mean by linear? (please open a Github issue to move the discussion) My dream visualization is in 3D, the flowers "stack up" on top of each other. I can also visualize in some way object identity equality... but i have no expertise to do that and not really the time to learn. (In reply to Boris Zbarsky (:bz) from comment #2) > WebIDL defines properties as being getter/setter pairs on the relevant > prototype. hmm... true. Maybe WebIDL should be refined, because Chrome organization sounds extremely relevant (both the fact that they define data properties and prototype chain). > XPConnect flattens all properties from the prototype chain onto most-derived > prototypes. This is not specific to event objects; it happens for > everything. There's an existing bug report on that, of which this looks > like a duplicate. Ok. I've searched on Bugzilla, but haven't found a bug. Hoepfully, someone will find it and solve this bug as duplicate. As long as there is already a bug on this issue, everything's fine.
> Maybe WebIDL should be refined, You may want to read the (lots of) existing discussion about that. Making the properties live on the prototype allows hooking them on all objects of a given type, which is something web developers commonly want.
(In reply to Boris Zbarsky (:bz) from comment #4) > > Maybe WebIDL should be refined, > > You may want to read the (lots of) existing discussion about that. I do. I'll dig public-script-coord. Other places i should look for for such discussions? > Making the properties live on the prototype allows hooking them on all objects of a > given type, which is something web developers commonly want. Actually, i've been wanted that in some cases as well :-p
I think the discussion was on some combination of webapi, webapps, whatwg, and html-wg. I'm pretty sure it predates script-coord.
Depends on: ParisBindings
Resolved <something>. We follow what the specs say - properties are getters/setters in prototype except unforgeable isTrusted. (and other engines should follow the specs too now)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.