1022040 - Make test-supplied chrome:// files available to the content process

Status: RESOLVED DUPLICATE of bug 687194

(Firefox :: General, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

One thing I've noticed is that, for at least browser-chrome tests, chrome:// support files for tests don't seem to be made available to the content process - the content process script loader seems to have no luck finding it.

My test in bug 989501 relies on a mochitest-provided content script, and it's totally busted if I run the test with --e10s, because it simply cannot find the file.

I would wager that any similar tests are likely hitting the same issue.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

So I looked at this a while tonight.

It looks like nsChromeRegistryChrome is used by ContentParent exactly once during its initialization to tell the content process to register the chrome packages that the ContentParent currently has in its own registry.

During a mochitest, the test packages are registered _after_ the ContentParent has been initialized, so that's why no mochitest content scripts can be loaded by the content processes.

I think we might need a way for the parent process to tell the child process that more things have been registered.

jdm - I saw you worked on the chrome registry stuff in bug 575918. In your opinion, is my understanding of the problem more or less right?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Whoops, forgot the needinfo.

Comment 3

[Josh Matthews [:jdm]]

Do you mean bug 687194, by chance?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(In reply to Josh Matthews [:jdm] from comment #3)
> Do you mean bug 687194, by chance?

That's _exactly_ what I mean. Thanks. :)