Heads up: add-ons using Places (bookmarks & history system) - API changes!

[Marco Bonardo]

(Please followup-to mozilla.dev.extensions)

Dear add-ons developers,
as part of our goal to make history and bookmarks asynchronous, we are
starting removing some APIs, that in the last years have been replaced
by new asynchronous ones.
We are currently removing the last uses in the tests harness, but we are
not too far from the target. Current goal is Firefox21.

The work is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=834457

The following APIs will be removed:

(replaced by mozIAsyncFavicons)
nsIFaviconService::setFaviconUrlForPage
nsIFaviconService::setFaviconData
nsIFaviconService::getFaviconData
nsIFaviconService::getFaviconForPage
nsIFaviconService::setAndLoadFaviconForPage
nsIFaviconService::getFaviconImageForPage
nsIFaviconService::getFaviconDataAsDataURL

(replaced by mozIAsyncLivemarks)
nsILivemarkService::*
PlacesUtils.itemIsLivemark
PlacesUtils.nodeIsLivemarkContainer
PlacesUtils.nodeIsLivemarkItem

(remove only third argument)
PlacesUIUtils.showBookmarkDialog

(no more implemented by Places, use mozIAsyncHistory)
nsIGlobalHistory2::addURI
nsIGlobalHistory2::isVisited
nsIGlobalHistory2::setPageTitle

In addition to this, if current issues will be solved soon, the
following will also be removed:

nsINavHistoryObserver::OnBeforeDeleteURI
nsINavBookmarkObserver::OnBeforeItemRemoved

Please let me know if you have doubts, or part of these changes should
be blocked for major problems, or there's some use-case you need that is
not well-covered by the new APIs.

Cheers,
Marco

[Marco Bonardo]

In addition to the previously notified Places deprecations, also the

following APIs will be removed:

(Never implemented properly)
nsINavHistoryFullVisitResultNode

(use mozIAsyncHistory::updatePlaces instead)
nsINavHistoryService::AddVisit

I posted a brief sum-up of all of the changes, for reference:
http://blog.bonardo.net/2013/01/29/add-ons-devs-heads-up-history-api-removals-in-places

Cheers,
Marco

[raa...@gmail.com]

Hey Marco,

> The following APIs will be removed:
>
>
>
> (replaced by mozIAsyncFavicons)
>
> nsIFaviconService::setFaviconUrlForPage
>
> nsIFaviconService::setFaviconData
>
> nsIFaviconService::getFaviconData
>
> nsIFaviconService::getFaviconForPage
>
> nsIFaviconService::setAndLoadFaviconForPage
>
> nsIFaviconService::getFaviconImageForPage
>
> nsIFaviconService::getFaviconDataAsDataURL

Is there a place where add-on authors can browse the API of the new and changed interfaces? Specifically, I'm interested in mozIAsyncFavicons and the related nsIFaviconDataCallback.

I've been using the docs on developer.mozilla.org, but the methods list in mozIAsyncFavicons is incomplete there, and nsIFaviconDataCallback is just wrong (the only method in it now has a different name).

Or are we supposed to just read .idl files in the Mozilla source tree?

[Jorge Villalobos]

Further down the line, we will document the changes in more detail in
the Add-ons Blog (for example:
https://blog.mozilla.org/addons/2013/02/07/compatibility-for-firefox-19/),
and MDN: https://developer.mozilla.org/en-US/docs/Firefox_20_for_developers.

At the moment, the best way to know what's going on is to look at the
patches. For example, the patch in bug 834457
(https://hg.mozilla.org/mozilla-central/rev/88fc7f93845c) shows that
nsIFaviconService only had its methods marked as deprecated, but weren't
removed.

As for documentation of the new APIs, it should remain up to date, but
documentation can often lag behind and your best bet is to read the
documentation in the IDL file instead.

Jorge

[Jorge Villalobos]

On 2/27/13 2:12 PM, Dmitry Gutov wrote:

> On 27.02.2013 23:58, Jorge Villalobos wrote:
>> Further down the line, we will document the changes in more detail in
>> the Add-ons Blog (for example:
>> https://blog.mozilla.org/addons/2013/02/07/compatibility-for-firefox-19/),
>>
>> and MDN:
>> https://developer.mozilla.org/en-US/docs/Firefox_20_for_developers.
>

> That's great, but still we probably won't see API details there.

>
>> At the moment, the best way to know what's going on is to look at the
>> patches. For example, the patch in bug 834457
>> (https://hg.mozilla.org/mozilla-central/rev/88fc7f93845c) shows that
>> nsIFaviconService only had its methods marked as deprecated, but weren't
>> removed.
>

> I believe that when an interface is marked deprecated (and especially
> when this deprecation is announced in several places), it's exactly
> the time when authors should start updating the addons, don't they?
>
> Personally, I'm usually running Aurora, so if I wait until the
> interface is removed, I won't notice that until a few unhappy Nightly
> users of the extension in question stumble on it.

Oh yeah, I didn't mean to discourage anyone from updating their code.
The sooner, the better, specially considering that it will improve
performance for both the add-on and Firefox.

>
>> As for documentation of the new APIs, it should remain up to date, but
>> documentation can often lag behind and your best bet is to read the
>> documentation in the IDL file instead.
>

> So, browse the source tree. Got it, thanks.
>
> --Dmitry

Yeah, I'm afraid there's no better solution at the moment :(. The MDN
team has been trying to get better / earlier doc updates from devs, but
it's a difficult process.

Jorge

[sont...@gmail.com]

This change will make my add-on "bookmark favicon changer" cannot run.
I agree with asynchronous when set favicon, but don't agree when get favicon.

Favicon is in history data, it should get easily - so it should be synchronous

Please look in my add-on "bookmark favicon changer" you will see long series of get and set favicon in one function. I cannot split it into many part without confusion.

More ever, when you hook function such as gbrowser.seticon
You can't return this hook function before every thing finish.

One sample code is in browser.js in bookmark favicon changer.

gBrowser.setIcon = function()
{
try {
var tabCurrentURI = gBrowser.getBrowserForTab(arguments[0]).currentURI;
var bookmarkURI = bookmarkfaviconchangerModule.bookmarksService.getBookmarkedURIFor(tabCurrentURI);
if (bookmarkURI==null) {
bookmarkURI = tabCurrentURI;
}
var originalFaviconURISpec = bookmarkfaviconchangerModule.annotationService.getPageAnnotation(bookmarkURI
,bookmarkfaviconchangerModule.pageOriginalFaviconURISpecNS);
// throw exception if no annotation data
try {
var faviconURI = bookmarkfaviconchangerModule.annotationService.getPageAnnotation(bookmarkURI,bookmarkfaviconchangerModule.pageFaviconDataURISpecNS);
} catch(e) {
var faviconURI = bookmarkfaviconchangerModule.faviconService.getFaviconForPage(bookmarkURI);
}
arguments[1] = faviconURI;
} catch(e) {
}
bookmarkfaviconchangerBrowser.setIcon.apply(this, arguments);
};


Please see - arguments[1] need before apply. And this function is in hooking process. I cannot make this asynchronous.

I am 100% disagree for get function to asynchronous.

Mozilla, please stop to break my add-on. You break it every 6 weeks. And it is unnecessary to do it.

[gerd.r...@gmail.com]

Dear all,

thank you very much for that information. Please allow me one question:

If I happen to have all required parameters, such as title, parentId, index and feedURI, available as single variables, how do I get them into a mozILivemarkInfo object as required now by addLivemarks()?

Thank you very much in advance and kind regards,

Gerd