Closed Bug 1016207 Opened 10 years ago Closed 8 years ago

livemark object internals are now exposed to consumers

Categories

(Toolkit :: Places, defect)

defect
Not set
normal

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.
See Also: → 1016202
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.
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.
backlog+ because it's ready to fix. Again, it's low priority in my opinion, and likely a "diamond" bug.
Flags: firefox-backlog+
Mentor: mano
Whiteboard: [diamond]
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.