Closed
Bug 1016207
Opened 10 years ago
Closed 8 years ago
livemark object internals are now exposed to consumers
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: asaf, Unassigned, Mentored)
References
Details
(Keywords: regression, Whiteboard: [diamond])
I overlooked the side-effect of the API changes I made in bug 896193. mozILivemarkCallback ensured that consumers get livemark objects in the form of a mozILivemark object, that is, after it was wrapped with XPConnect. Now that a promise is used instead of the callback, consumers get the raw js object, with all of its internals exposed (it's not frozen or even sealed). I'm not sure if fixing that is worth the time, but I sure didn't intend to cause this change.
Reporter | ||
Comment 1•10 years ago
|
||
Per my comment in the other bug, I think mozILivemark should be removed, and its implementation should be fixed not to expose internal stuff as much as possible. Low priority though.
Reporter | ||
Comment 2•10 years ago
|
||
On a side note, it's not just "internal stuff". The raw object semantics differ from what's in the interface. the status property can be set (readonly in the IDL), and some methods have the look and feel of public methods, even though they're public in the "friend class" sense, meaning they're supposed to be used by other objects in nsLivemarksService.js. Hopefully we won't see addons starting to use writeFeedURI once this comment is posted.
Reporter | ||
Comment 3•10 years ago
|
||
backlog+ because it's ready to fix. Again, it's low priority in my opinion, and likely a "diamond" bug.
Flags: firefox-backlog+
Updated•10 years ago
|
Mentor: mano
Whiteboard: [diamond]
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•