Trivial test, cut down from my real code: /* Any copyright is dedicated to the Public Domain. * http://creativecommons.org/publicdomain/zero/1.0/ */ "use strict"; const {utils: Cu} = Components; function run_test() { run_next_test(); }; add_test(function use_os_file() { Cu.import("resource://gre/modules/osfile.jsm") let iterator = new OS.File.DirectoryIterator("."); iterator.forEach(function onEntry(entry) { print("Got " + entry.path); }).then(function onSuccess() { iterator.close(); print("Done."); run_next_test(); }, function onFail() { iterator.close(); print("Failed."); run_next_test(); }); }); Produces output: 0.68 TEST-INFO | (xpcshell/head.js) | test 2 finished 0.68 Got ./head.js 0.68 Got ./test_load_modules.js 0.68 Got ./test_load_modules.js~ 0.68 Got ./test_profile.js 0.68 Got ./xpcshell.ini 0.68 Got ./xpcshell.ini~ 0.68 Done. 0.68 0.68 TEST-INFO | (xpcshell/head.js) | test 2 pending 0.68 0.68 TEST-INFO | (xpcshell/head.js) | test 2 finished 0.68 0.68 TEST-INFO | (xpcshell/head.js) | test 1 finished 0.68 0.68 TEST-INFO | (xpcshell/head.js) | exiting test 0.68 0.68 TEST-INFO | (xpcshell/head.js) | No (+ 0) checks actually run 0.68 WARNING: nsExceptionService ignoring thread destruction after shutdown: file /Users/rnewman/moz/hg/services-central/xpcom/base/nsExceptionService.cpp, line 166 0.68 ###!!! ASSERTION: This should never be null!: 'stack', file /Users/rnewman/moz/hg/services-central/dom/workers/RuntimeService.cpp, line 1431 0.68 mozilla::dom::workers::RuntimeService::AutoSafeJSContext::AutoSafeJSContext(JSContext*)+0x00000017 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x00BBFA57] 0.68 mozilla::dom::workers::RuntimeService::Cleanup()+0x000002B6 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x00BBCFD6] 0.68 mozilla::dom::workers::RuntimeService::Observe(nsISupports*, char const*, unsigned short const*)+0x0000007A [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x00BBFA1A] 0.68 nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*)+0x00000054 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x01853204] 0.68 nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*)+0x00000121 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x018544C1] 0.68 mozilla::ShutdownXPCOM(nsIServiceManager*)+0x000001C6 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/XUL +0x0183CD46] 0.68 main+0x00000D21 [/Users/rnewman/moz/hg/services-central/obj-ff-dbg/dist/bin/xpcshell +0x00003B31] 0.68 ###!!! ASSERTION: This should never be null!: 'stack', file /Users/rnewman/moz/hg/services-central/dom/workers/RuntimeService.cpp, line 1431 0.68 <<<<<<< 0.69 PROCESS-CRASH | %s | application crashed (minidump found) Crash dump filename: /Users/rnewman/moz/hg/services-central/obj-ff-dbg/_tests/xpcshell/services/healthreport/tests/xpcshell/AA23DA89-47E0-4D64-B0AE-72E8E53D0CBC.dmp MINIDUMP_STACKWALK not set, can't process dump. 0.69 INFO | Result summary: INFO | Passed: 0 INFO | Failed: 1 INFO | Todo: 0

I am surprised that OS.File even launches with xpcshell, given that it depends on 1/ dom workers 2/ constants defined in a DOM module. jorendorff, I thought we had access to neither in xpcshell, am I wrong?

(In reply to David Rajchenbach Teller [:Yoric] from comment #1) > I am surprised that OS.File even launches with xpcshell, given that it > depends on 1/ dom workers 2/ constants defined in a DOM module. > > jorendorff, I thought we had access to neither in xpcshell, am I wrong? So... any feature we want to test with xpcshell has to use nsIFile? Or is this something you want to get working for fx18? (It seems to work otherwise!)

I echo Richard's sentiment. The inability to use OS.File from xpcshell is kind of a deal breaker. xpcshell tests are used for lots of unit testing of JSMs and I would hate to be forced to use a more heavyweight testing framework. Please make OS.File work with xpcshell!

I would love OS.File to work with xpcshell but until now, I assumed that there was no chance to ever make it work. Now, this bug gives me hope that it can work after all, which would be great news. I will look into it next week.

(In reply to David Rajchenbach Teller [:Yoric] from comment #4) > I would love OS.File to work with xpcshell but until now, I assumed that > there was no chance to ever make it work. > > Now, this bug gives me hope that it can work after all, which would be great > news. I will look into it next week. That would be excellent. This is for a feature that we'd like to ship in 18, so if you can make that schedule work, we'd be really happy!

(In reply to David Rajchenbach Teller [:Yoric] from comment #1) > I am surprised that OS.File even launches with xpcshell, given that it > depends on 1/ dom workers 2/ constants defined in a DOM module. All the DOM code is available in xpcshell, you just can't instantiate a real DOM document, AFAIK.

I found a trivial bug in the js code of OS.File (we attempt to close the directory twice), but nothing that should be able to cause such a crash. Bent, you have written the line that asserts, could you help me figure out the issue?

There's a fix in bug 808428 for the immediate issue, but note that DOM workers rely extensively on the main event loop and xpcshell has very weird event loop behavior. You may find yourself needing to spin up an event loop manually to get code using workers to behave properly.

Marking this as fixed.