1498404 - Fix some errors in manifests

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

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&regexp=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.

Comment 1

[Andrew McCreight [:mccr8]]

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.

Comment 2

[Andrew McCreight [:mccr8]]

Attachment: Bug 1498404 - 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.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a3521c2b925b
Fix some errors in manifests r=froydnj

Comment 4

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/a3521c2b925b