Closed
Bug 778089
Opened 12 years ago
Closed 6 years ago
Allow expandos on COWs
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: bholley, Unassigned)
Details
Split off from bug 760109 comment 40.
This will be tricky, because our current mechanism for expando objects involves placing hanging expando objects off a reserved slot in compartment of the wrappee. This works when we know what kind of object we're dealing with (XPCWNs), but COWs can be any arbitrary JS object. And we certainly don't want to add an extra reserved slot to every JS object just for this?
Luke, how feasible is it to add a mechanism whereby we can add a reserved slot or something like it? Specifically we want something that's not visible to script but is visible to the GC. I don't think we care if it causes us to nuke jitcode and such.
Comment 1•12 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #0)
I agree we definitely should not add a slot to every object.
> Luke, how feasible is it to add a mechanism whereby we can add a reserved
> slot or something like it? Specifically we want something that's not visible
> to script but is visible to the GC.
I don't quite understand; are you asking how we could dynamically add reserved slots? That would be enormously hard, I think.
What about using a WeakMap?
Reporter | ||
Comment 2•12 years ago
|
||
(In reply to Luke Wagner [:luke] from comment #1)
> What about using a WeakMap?
Was thinking more about this today - that's probably the way to go.
Comment 3•12 years ago
|
||
Do you know a workaround for this? (e.g. a object that delegates to chrome code for some methods but that can be exposed to the content code...)
A case where this breaks stuff is due to the google closure library that fails to attach ids to some objects.
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to Giuseppe Angelone from comment #3)
> Do you know a workaround for this? (e.g. a object that delegates to chrome
> code for some methods but that can be exposed to the content code...)
> A case where this breaks stuff is due to the google closure library that
> fails to attach ids to some objects.
You could try making the object itself a content object and have it call various chrome methods. See Components.utils.createObjectIn for a mechanism for creating objects directly in content.
Comment 5•12 years ago
|
||
(In reply to Bobby Holley (:bholley) (on vacation though Dec 4) from comment #4)
> You could try making the object itself a content object and have it call
> various chrome methods. See Components.utils.createObjectIn for a mechanism
> for creating objects directly in content.
Thanks, it worked. See https://forums.mozilla.org/addons/viewtopic.php?f=7&t=11300
Comment 6•6 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•