I tried to remove this xpi in bug 1455956 but, somehow, SpecialPowers.jsm depends on it. This file is not used anymore and it can be removed.

I just ran into this too. It's not just specialpowers. Other parts of the mochitest harness fail, too. Apparently their frame scripts don't get loaded into new content process when the extension isn't there. They don't depend on anything the extension does. Just replacing it with a skeleton extension with only an install.rdf fixes the problem.

OK. I see the problem now. Without the workerbootstrap-test extension, we don't have any extensions installed in the profile during early startup, which means that the profile extensions directory doesn't exist. Since it doesn't exist, it doesn't get added to the content sandbox filesystem whitelist, which means that profile extension contents are not available in sandboxed content processes.

Comment on attachment 8979063 [details] Bug 1460610: Fix content process whitelist for profile extensions when none are present at startup. https://reviewboard.mozilla.org/r/245324/#review252394 Can we just fix the sandboxing code to unconditionally whitelist the extensions directory?

Comment on attachment 8979063 [details] Bug 1460610: Fix content process whitelist for profile extensions when none are present at startup. https://reviewboard.mozilla.org/r/245324/#review252394 No, I'm pretty sure we can't whitelist directories that don't already exist.

Comment on attachment 8979063 [details] Bug 1460610: Fix content process whitelist for profile extensions when none are present at startup. https://reviewboard.mozilla.org/r/245324/#review252394 well that's a bummer...

Comment on attachment 8979063 [details] Bug 1460610: Fix content process whitelist for profile extensions when none are present at startup. https://reviewboard.mozilla.org/r/245324/#review252410

https://hg.mozilla.org/integration/mozilla-inbound/rev/120d17a176ffa033fe79632804755ae23940c336 Bug 1460610: Fix content process whitelist for profile extensions when none are present at startup. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/7398284f1d7f62748dcc7eb556a24b5e0ee11bba Bug 1460610: Follow-up: Fix test expectations. r=bustage DONTBUILD

https://hg.mozilla.org/mozilla-central/rev/120d17a176ff https://hg.mozilla.org/mozilla-central/rev/7398284f1d7f

Interestingly this causes a problem in Telemetry xpcshelltests. Specifically, ./mach test toolkit/components/telemetry/tests/unit Now fails with the following message: Error running mach: ['test', 'toolkit/components/telemetry/tests/unit'] The error occurred in code that was called by the mach command. This is either a bug in the called code itself or in the way that mach is calling it. You should consider filing a bug for this issue. If filing a bug, please include the full output of mach, including this error message. The details of the failure are as follows: ErrorMessage: Symlink target path does not exist: /home/chutten/mozilla-central/dom/workers/test/extensions/bootstrap/workerbootstrap-test@mozilla.org.xpi File "/home/chutten/mozilla-central/testing/mach_commands.py", line 167, in test argv=extra_args, test_objects=tests, **kwargs) File "/home/chutten/mozilla-central/python/mach/mach/registrar.py", line 129, in dispatch return self._run_command_handler(handler, context=context, **kwargs) File "/home/chutten/mozilla-central/python/mach/mach/registrar.py", line 90, in _run_command_handler result = fn(**kwargs) File "/home/chutten/mozilla-central/testing/xpcshell/mach_commands.py", line 229, in run_xpcshell_test driver.install_tests(test_objects) File "/home/chutten/mozilla-central/python/mozbuild/mozbuild/controller/building.py", line 1341, in install_tests '_tests', test_objs) File "/home/chutten/mozilla-central/python/mozbuild/mozbuild/testing.py", line 267, in install_test_files remove_unaccounted=False) File "/home/chutten/mozilla-central/python/mozbuild/mozpack/copier.py", line 431, in copy copy_results.append((destfile, f.copy(destfile, skip_if_older))) File "/home/chutten/mozilla-central/python/mozbuild/mozpack/files.py", line 336, in copy raise ErrorMessage('Symlink target path does not exist: %s' % self.path) What makes this _extra_ interesting is that ./mach xpcshelltest toolkit/components/telemetry/tests/unit runs just fine.

:chutten, does a clobber fix the problem reported in comment 11?

Sorry for the delay. Yes, it seems a clobber takes care of it.

I can't explain the "mach test" vs "mach xpcshell-test" difference but this is pretty typical when something is removed from the build. I'm not sure how we should handle this properly, touching CLOBBER would mean a bunch of recompilation for people not working with artifact builds who may not be affected by this...

|mach test| does some extra querying into the build system that the individual test commands don't need to do, so it's not terribly surprising. I guess it depends how widespread this issue is, but IMO it's usually better to touch CLOBBER when things like this arise. The time developers will spend trying to figure this issue out will likely exceed the time they would waste waiting for a CLOBBER build (especially since they can do other things while compiling).