Use our new binding proto setup for custom element prototypes when possible

RESOLVED FIXED in Firefox 39

Status

()

Core
DOM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla39
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment)

The patch checked in for bug 1130028 seems to rely on post-wrapping SetPrototype calls, and in particular on the prototype set happening on the Xray, not on the object itself.

This, unfortunately, does not play nice at all with what I was trying to do in the "part 4" patch in bug 1117172.

The reason I'd like to do _something_ there is that in the common case of all the stuff being part of the webpage we don't want to do the dynamic JS_SetPrototype business: that deoptimizes the object and makes performance-me very unhappy.

Seems to me like if NodePrincipal() subsumes the compartment principal of the proto we should be able to just pass it in as-is.  Otherwise, do what we do now.  Seem reasonable?
Created attachment 8579823 [details] [diff] [review]
Use the new proto setup for custom element prototypes when possible

Note that with this patch I'm also changing the priority order of the given
proto and the custom proto; the former takes priority.  This makes sense to me:
if the caller is doing |new Foo| they really should get something with
Foo.prototype as its proto.  This should not be a problem for custom elements
in general so far, because nodes/elements are mostly not constructible anyway.
For now.  When they become that way, I think this is the behavior we'll want.
Attachment #8579823 - Flags: review?(wchen)
Attachment #8579823 - Flags: review?(bobbyholley)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #8579823 - Flags: review?(bobbyholley) → review+

Updated

3 years ago
Attachment #8579823 - Flags: review?(wchen) → review+
https://hg.mozilla.org/mozilla-central/rev/6030e30ae43d
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.