This ticket tracks adding a component registration filtering mechanism to allow background tasks to selectively enable and disable components. This is needed to stop, for example, nsBrowserGlue.js from loading, profile-after-change events loading a lot of Firefox specific code, etc.

Philosophically, this is roughly equivalent to declaring a new application ID, different from Firefox's application ID (ec8030f7-c20a-464f-9b0e-13a3a9e97384). There are only ~50 references to Firefox's application ID at this time. But we believe that it will be better for background tasks to be as similar to the regular application (Firefox, but potentially also Thunderbird) as possible, and a new application ID for every background task, would be onerous, so we would prefer to allow filtering by background task without monkeying with the application ID.

Next, implementation. Assume throughout that there is some globally accessible Maybe<nsCString> that stores Some("background task name") if the application is invoked in background task mode.

Right now there are two mechanisms for registering XPCOM components: chrome manifests, handled by ManifestParser.cpp and static registration, handled by StaticComponents.h and related infrastructure.

It is straightforward to teach ManifestParser about a new restriction of the form backgroundtask=..., in the same manner as application=... is handled, and to use the globally accessible background task name to filter against.

The static component registration system is more onerous, which is why I'd like to get feedback from peers before implementing this change. (For local testing I am filtering based on XPCOM notification name rather than being data driven and encoding the filtering into components.conf files.)

This allows to filter chrome manifest registration by the current
background task(s, in the future). Filtration behaves just like
filtering by "application":

• filter with backgroundtask= means disable for all background
  tasks, since no background task will match ""

• filter with backgroundtask!= means enable for all background task,
  since every background task will not match ""

Depends on D96481

kmag: hello! Before implementing something, I'd like to get some feedback from you. What I want to do is add a "background task mode" to Firefox, so that when you run firefox --backgroundtask FOO the XPCOM graph and category registrations can depend on the specified background task. The commit that I've flagged you for feedback on shows what I mean to do for filtering chrome.manifest registrations, but I'd like to get your opinion on this approach before doing this for categories entries in static components.conf files. Would you be okay generalizing

Classes = [
    {
        'cid': '{5d0ce354-df01-421a-83fb-7ead0990c24e}',
        'contract_ids': ['@mozilla.org/browser/clh;1'],
        'jsm': 'resource:///modules/BrowserContentHandler.jsm',
        'constructor': 'nsBrowserContentHandler',
        'processes': ProcessSelector.MAIN_PROCESS_ONLY,
        'categories': {
            'command-line-handler': 'm-browser',
        },
    },
]

to restrict category registration like

        'categories': {
            'command-line-handler': {
                'category': 'm-browser',
                'backgroundtasks': ['FOO', 'BAR'],
            },
        },

If you're not the right person to talk to about this, or you're too busy to deal with this, please redirect! I'm happy to try to provide more context on what we're doing as well, since this is a new use case for Firefox/Gecko.

(In reply to Nick Alexander :nalexander [he/him] from comment #2)

kmag: hello! Before implementing something, I'd like to get some feedback from you. What I want to do is add a "background task mode" to Firefox, so that when you run firefox --backgroundtask FOO the XPCOM graph and category registrations can depend on the specified background task.

I'm OK with the general idea, but I'd rather we only add support to the new static XPCOM manifest system and not to old-style chrome.manifest files. I'd rather not encourage people to use the latter for new code. Ideally I'd like to remove support for them at some point.

        'categories': {
            'command-line-handler': {
                'category': 'm-browser',

Nit: this should be something like 'name' or 'entryName', not 'category'. The category, in this case, would be command-line-handler, and m-browser would be the name of this entry.

(In reply to Kris Maglione [:kmag] from comment #3)

(In reply to Nick Alexander :nalexander [he/him] from comment #2)

kmag: hello! Before implementing something, I'd like to get some feedback from you. What I want to do is add a "background task mode" to Firefox, so that when you run firefox --backgroundtask FOO the XPCOM graph and category registrations can depend on the specified background task.

I'm OK with the general idea, but I'd rather we only add support to the new static XPCOM manifest system and not to old-style chrome.manifest files. I'd rather not encourage people to use the latter for new code. Ideally I'd like to remove support for them at some point.

Understood, but there's a good deal of category registration that I need to disable for my immediate use case. I don't think we can commit to completing the transition to static components for this particular project.

        'categories': {
            'command-line-handler': {
                'category': 'm-browser',

Nit: this should be something like 'name' or 'entryName', not 'category'. The category, in this case, would be command-line-handler, and m-browser would be the name of this entry.

Roger that. I'll knock something up and have you review it. Thanks for the snappy reply, Kris!

For simplicity, this implements just on in NO_TASKS (the default) or
on in ALL_TASKS (opt-in). This disables all category registrations
when in background task mode; we'll selectively re-enable things as
appropriate.

The flag constants were chosen to smoothly extend to a (16-)bit set in
the future, should we want to add a JUST_TASKS("task", "other-task")
option in the future.

Depends on D96482

Depends on D96654

https://hg.mozilla.org/mozilla-central/rev/2583e49a1876
https://hg.mozilla.org/mozilla-central/rev/de448d4fbef2
https://hg.mozilla.org/mozilla-central/rev/e33d312c5da2