In bug 1438688 (part 2), I made it so that "interfaces" is no longer a valid entry in a manifest. I think I cleaned it out of some of the standard manifests at that time, but it appears there are a few testing related manifests where it is still present: https://searchfox.org/mozilla-central/search?q=interfaces&case=false®exp=false&path=.manifest Fun fact: when I do mach run in a local build, these manifests hit an error while loading httpd.manifest, and going through the process of logging that error message seems to be the place that causes us to first run the Initialize() method in nsLayoutModule.cpp which is alarming.
We should probably make these manifest parsing errors at least assert. Also, it seems bad that we can end up accidentally changing where we start up XPConnect like this.
Summary: Remove remaining interfaces entries from manifests → Fix some errors in manifests
In FxAccountsComponents.manifest, the previous line registers the component CID, but only for the main process. This means we hit an error while parsing the manifest in the child process, because the CID is not recognized. The fix is simply to not try to use the CID to register the contract in the child process. As for the rest of the changes, since bug 1438688, XPT information is compiled into the Firefox binary, so the interfaces manifest entry is no longer needed. This patch removes instances of this line from manifest files. This makes some manifest files empty, so the patch also removes the now-empty files.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/a3521c2b925b Fix some errors in manifests r=froydnj
You need to log in before you can comment on or make changes to this bug.