1418257 - WebExtension bookmarks API returns type "folder" for a live bookmark and no URL

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P3)

Description

[voltron]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

1. Create a WebExtension skeleton
2. In the JavaScript code get all bookmarks:

var tree = browser.bookmarks.getTree()
tree.then(handleTree, errorHandler);
...

3. Parse until you encounter bookmarks.BookmarkTreeNode that is actually a Live Bookmark


Actual results:

BookmarkTreeNode that represents a Live Bookmark returns "folder" as the type and has no "url" attribute. This makes it impossible to properly export Live Bookmarks as OPML for example (which is our real-life use case for this).


Expected results:

BookmarkTreeNode representing a Live Bookmark should return "livebookmark" as type and it should have "url" attribute that points to the source (i.e. feed URL).

Comment 1

[Bob Silverberg [:bsilverberg]]

We don't currently support "livebookmark" as a type, but maybe we should. Marco, what is your opinion about this?

Comment 2

[Marco Bonardo [:mak]]

It's complicate to answer this, livemarks (or live bookmarks, as you prefer) currently are empty folders with an annotation, so the type we return is correct, it's a folder. The problem here is that an add-on has absolutely no way to tell it's a special folder, and even if it had, it has no way to fetch the feeduri and the siteuri.
While introducing a new type sounds like a solution, I have no idea of the long term future of livemarks, there's some work in bug 1350349 to better understand usage of the feature. There's some risk to introduce a type that may become completely obsolete in 1 or 2 years. If we'd decide to remove livemarks, or move them to Activity Stream, for example, how do you manage the obsolete type in the API? If this is not a problem, then we can do whatever we wish.
Note that once we have this type, it's plausible the next request will be to create such a type from the API, and then you'll need to fix the create API, that enlarges the reach of the change. Maybe even other APIs will have to adapt.

A good solution instead may be to fix an old bug that suggested changing livemarks to queries (bug 1072833). We could make a special kind of query like "place:feed=feeduri&uri=siteuri", that would also have the advantage to completely remove the need for annotations and may simplify a lot of our code as well. It sounds like a very good idea off-hand!
Unfortunately we're totally non resourced to work on that, in general livemarks work has the lowest priority possible, because it's a niche feature. I could play a little bit with that during Christmas vacations, but I cannot anticipate how hard it will be to support such a change in Sync (surely it would be totally non-backwards compatible for the profile).

Comment 3

[Marco Bonardo [:mak]]

I started looking into bug 1072833 during the weekend, and I think it would allow to fix this in a simple way without even changing the public API. It may take some time before the patch it's ready because it touches lots of files, but it has various advantages, apart from just fixing this bug, and thus I think it's worth it.

Comment 4

[Bob Silverberg [:bsilverberg]]

(In reply to Marco Bonardo [::mak] from comment #3)
> I started looking into bug 1072833 during the weekend, and I think it would
> allow to fix this in a simple way without even changing the public API. It
> may take some time before the patch it's ready because it touches lots of
> files, but it has various advantages, apart from just fixing this bug, and
> thus I think it's worth it.

Thanks Marco. How will this impact the WebExtensions API? Will this change mean that livemarks would not be returned from any browser.bookmarks API methods? As I understand it, the use case is not to exclude livemarks but to have them returned with a unique type and include the feed URL. Will that data be available to the bookmarks API code after the change for bug 1072833 has been made?

Comment 5

[Marco Bonardo [:mak]]

If you currently don't filter out bookmarks with a "place:..." uri, feeds will just be returned as bookmarks with a "place:" uri as well. They will look like a normal bookmark with an uri like "place:feed=someuri&feedSite=someotheruri". the feeduri and siteuri can be extracted from the place uri itself.

Comment 7

[Marco Bonardo [:mak]]

Wontfixing because live bookmarks are going away - See Bug 1477667.