Closed Bug 1016202 Opened 10 years ago Closed 7 years ago

Wrap livemark-items nodes with xpconnect

Categories

(Toolkit :: Places, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: asaf, Unassigned)

References

Details

I think that for general sanity it's a good idea to wrap livemark-items nodes with xpconnect, even if that involves a somewhat nasty-but-harmless hack.

What hack would that be though? My initial thought was creating a writable variant, setting its value to the node object with setAsInterface, and then get variant value. Problem is, you cannot get the variant value: all nsIVariant methods are [noscript], meaning that in js variants are only writable.

So, the next-least-evil on the list is nsIPropertyBag. The object could be set as an interface property (setAsInteface) and then simply be read with |get|. That actually works.
Actually, I think we can just fix the signature of getNodesForContainer.
Ah, crap, because mozILivemarkCallback is now replaced by a promis-return value, it's the mozILivemark objects that are no longer wrapped, meaning that getNodesForContainer signature is meaningless.
See Also: → 1016207
I talked with Blake Kaplan about this issue (and bug 1016207) yesterday. He suggested a new Components.utils.makeXPCOM API, but was not so enthused by the idea, and I personally would consider that a move against our de-xpcom trend. So, I think that we should COMify only what we really makes sense - that is just the faked nodes (because the results API is going to remain in XPCOM for the foreseeable futrue). We can do that with the property bag trick I suggested in comment 0. De-facto unused mozILivemark, however, should probably go away at this point (I'll keep that for bug 1016207).
Assignee: asaf → nobody
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.