More work on code generator; Services.jsm;

Written on Jul 30, 2018

Hiding old Services object and exposing the one generated via template

So I have added all services from Services.jsm to Services.py and firefox has compiled successfully, but one of the errors I get upon starting Firefox is that Services.search is undefined. I define Services.search if MOZ_TOOLKIT_SEARCH is defined. But it seems as though MOZ_TOOLKIT_SEARCH is not defined, even though it’s needed. Let’s try to figure out how to define it.

I found this code bit.

for var in ('MOZ_TOOLKIT_SEARCH',
            'MOZ_SYSTEM_NSS',
            'MOZ_UPDATER',
            'MOZ_ANDROID_MOZILLA_ONLINE',
            'MOZ_SWITCHBOARD'):
    if CONFIG[var]:
        DEFINES[var] = True

So I added the following to xpcom/build/moz.build

for var in ('MOZ_TOOLKIT_SEARCH',
            'MOZ_CRASHREPORTER',
            'MOZ_GECKO_PROFILER',
            'ANDROID'):
    if CONFIG[var]:
        DEFINES[var] = True

because all of the above are mentioned in Services.jsm.

Services.blocklist.pluginQueries

I am running firefox, and while most of the things are working, I am getting the following error in the console:

... TypeError: Services.blocklist.pluginQueries is undefined (resource://gre/modules/Blocklist.jsm:310:1) JS Stack trace: _init@Blocklist.jsm:310:1

So turns out Blocklist service, similar to CrashManageris also defined in JavaScript. I need to figure out how to expose it to C++.

Next steps and observations

• Searching for "@mozilla.org/extensions/blocklist;1" in cpp files shows that when a service is retrieved using the above contract id, it is treated as nsIBlocklistService.
• There is a header file for nsIBlocklistService class
• So this service defined from JavaScript gets exposed to C++ somehow, so I should be able to figure out just from searching for blocklist or for nsIBlocklistService
• There is this extensions.manifest file, and I am not sure if I need this as well
  • I could check if there is extensions.manifest
• Nevermind. I think what’s important here is that it seems that C++ code can use do_GetService to obtain nsIBlocklistService.
• So it seems like we are obtaining Blocklist service correctly, but not all of the expected methods are exposed
• Do we need to query for another interface perhaps? Let’s see. Need to search for pluginQueries
• Why is Blocklist defined in several places?
  • I looked at the blame of both files, and traced the creation of the second Blocklist definition back to this bug.
  • So it seems like Blocklist.jsm is just a stub
• I think there are two problems at this point
  1. Services.blocklist.pluginQueries is not defined, and I think perhaps that due to the field not being specified in the interface in the idl files
  2. Services.blocklist.isLoaded returns false when I comment out the old Service object and use mine, and returns true when the old Service object is used globally
• Let’s first figure out #2. Cu.isModuleLoaded(BLOCKLIST_JSM) returns false, so I guess we are not loading it properly when we are exposing it via C++.
• Summary of the problem so far: Blocklist service is not defined purely in Blocklist.jsm. What we have in Blocklist.jsm is only a stub, and the real implementation is located in toolkit/mozapps/extensions/addonManager.js. The real implementation also contains some fields that are not exposed through idl. Should we go ahead and
• Update, so my mentor said I should be using WrappedJsObject instead.

Update to my code generator

• Child process message manager does not need custom service retrieval and can be retrieved in the same way as others, even though it is exposed via webidl
• Defines are available at build time, so already in the python script I can choose not to generate certain service getters
• To be continued tomorrow…

Useful links

• Creating XPCOM components pdf