Closed Bug 598884 Opened 12 years ago Closed 6 years ago

Create a special content-process harness for xpcshell tests


(Core :: IPC, defect)

Not set





(Reporter: cjones, Unassigned)



Single-process xpcshell tests are graphics/toolkit/platform-neutral, enough to be headless anyway.  We broke that with multi-process xpcshell tests, because we only have one content process implementation, and it needs to use the platform toolkit for all the things firefox-bin needs to use the platform toolkit for.  This led to bug 575918, and causes similar on headless linux systems.

One way to sort this would be with a slightly different content-process-xpcshell path.  Instead of going through normal ContentChild initialization, which includes gfx setup, then using a "UI event loop", we would instead take a slightly different startup path and then use ... another kind of event loop.  We can't use the XPCOM event loop directly because we need IPC.  We should theoretically be able to use an IO loop on the main thread, the same type as the IO loop on the IO thread.  This would work just fine with libevent; no idea about the windows backend.  (With that, we might also need to trick some code into thinking that the main-thread's event loop is a UI loop, or some assumptions could break.  Or we could just fix those assumptions.)

It's probably easier to fix this generally than to hack something for OS X in bug 575918.  If whoever takes this bug agrees, plz dup to this.
I really don't think we want to spend time trying to make xpcshell headless. I think we'd be better off running firefox-bin -xpcshell (which we've wanted to do for other static-firefox reasons), if that will solve the problem.
Single-process xpcshell is headless.  |firefox-bin -xpcshell| doesn't really solve the problem so much as define it away, but that's totally fine with me, less work!
When you say "is headless" what do you mean? Can we just define it as "must have a head" and move on?
"Doesn't need a head".  Sure, that's an option.
Is this still relevant/wanted?
Flags: needinfo?(wmccloskey)
If "is headless" means "doesn't initialize GTK/Win32/whatever", then I think I broke this for even single-process xpcshell a while ago in order to make WebExtensions tests work in xpcshell. A few people were bothered but it didn't seem to be a big deal. I don't think we need this at all.
Closed: 6 years ago
Flags: needinfo?(wmccloskey)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.