For testing in bug 814257, it's most useful to us if our unit tests are realistically testing worker behaviour. This implies running our tests in a real content (non-XUL) window context rather than running in an exclusively shimmed context, as we do now. Because these changes imply abandoning use of the xpcshell contributed globals, it seems like a good time to also switch to using xpcwindow for running our tests and abandoning much of the xpcshell test infrastructure, specifically the misleading bit where we claim our test passed from an xpcshell perspective even if it failed. There are no real direct complexities from this change; it's the introduction of the worker that will complicate things somewhat because we will have two contexts where we previously had one. This complicates test code that previously was easily able to manipulate the back-end and front-end like they were in the same context. Because the actors/loggers are orthogonal and most logging happens in the back-end, this should not be particularly hard to deal with, although initial solutions may be a little ugly...
Bad news: Although we can instantiate a docshell from scratch in xpcshell, we can't get it a scripting context (which also serves as nsIDOMWindow) without a proper top-level window hierarchy. nsDocShell::EnsureScriptEnvironment wants an mTreeOwner that not only exists but also implements nsIWebBrowserChrome. JS can't implement the required interfaces, so that does't work. Although I can get at nsIAppShellService from xpcshell and try and create top-level windows, there seems to be a fundamental linkage problem that precludes creating a GTK nsIAppShell. Ci.nsIAppShell is undefined. Although appShellService.createTopLevelWindow() can be invoked and it causes some GTK stuff to happen, from the many warnings, it appears gtk_init was not called. Control flow never returns from that process, so it's conceivable control is diverted into the gtk main-loop, but without our native event loop owned by the appshell, we can't get control flow back. Since xpcshell seems like a bust and we need to spin up real windows and such anyways, the implication from this is that we want to just use something operating in a xulrunner mode of operation. Good news: b2g-desktop supports a xulrunner mode of operation! Bad news: It's a little weird: the preload subprocess still gets spun up, and there's basically no way to kill the b2g instance frmo the console. At that point, we're getting reasonably close to gaia's integration test harness, so we want to try and avoid duplicating effort there. But since this is already getting pretty scary in terms of changes, I think the right course of action for now is to have the test-runner do the xulrunner app thing to run us, but to try and structure things so that it wouldn't be too much extra work to run under the integration harness. Which translates mainly to having the tests spun up in content-space in a fairly loader-agnostic fashion, so rather than having shims/mocks be externally forced into our web context, it gets done by in-content clobberings as part of the test. So the loader mainly just takes the name of the test/tests to run, sets up the protocol mapping, generates any permissions required (if we go with non-chrome privs) sets up the iframe, runs them, and dumps the logger output(s) to disk with minor introspection to know what return code to emit or short console output to dump.
This landed as part of bug 814257. Marking WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.