Should I import Services.jsm? Is it useful for extension authors?

[eyalroz]

Michael Kluge (@thundernest) asked:

If I want to do things that the WebExtension APIs do not support, it looks like I need to use ChromeUtils.import and import some magic that does stuff that is not documented anywhere:
...
var { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm");

The WebExtensions APIs are well documented, but soon after I tried Google for a documentation of ... what ... could be imported with ChromeUtil.import I had the feeling to enter a dark cave.

So:

• What "services" are in Services.jsm?
• Is it useful for extensions to import that module?

[cleidigh]

@eyalroz
@thundernest
Services.jsm provides method access to any of the core Thunderbird modules, you could also consider it a new access mechanism replacing the older styles. It provides access to everything from console to preferences. Below is a link to the documentation. Note you can use the services from experiments not background or content scripts.
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Services.jsm
@cleidigh

[eyalroz]

@cleidigh :
But if we use it from within an experiment - i.e. from "regular plain old extension code" - why would we want to access services through Services.jsm, rather than the old way? Let's take one of the first services in there for example: appinfo. We've been writing this:

var appInfo = Components
    .classes["@mozilla.org/xre/app-info;1"]
    .getService(Components.interfaces.nsIXULAppInfo);

and instead we can write this:

const {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
var appInfo = Services.appinfo;

granted, it's less verbose. But other than that, what's the benefit?

[cleidigh]

@eyalroz
Good point. I glossed over that.
First, as you have for longer experience with Thunderbird then I do, using services is how I have been doing pretty much everything. I do not want to speak absolutely authoritatively, however, as I remember when I was starting with code Services.jsm accomplishes two things

• simplification of code (you pointed out)
• faster call cycle (I would have to find this as a reference)
  Beyond that I am not sure if there are other benefits.

[eyalroz]

@cleidigh : More questions:

1. Is Components.classes going to go away anytime soon though?
2. When did Services.jsm become available? That is, if we adopt it, at which TB version are we breaking compatibility?
3. I think at least some of these services are available even without the importation. Like the console. Are there other such examples?

[cleidigh]

@eyalroz
Hey what do you think I'm some sort of Thunderbird Guru ?? ;-)

1 - For legacy context (60.x and experiments) I think Cc, Ci, Cu still needed as everything is not under services
2 - no idea, again I think it's only relevant for experiments
3 - the JavaScript console yes but services and some of its own functions