I've mentioned this before [1], but recent checkins in mozilla-central suggest that this message could use repeating.
Please don't write new tests that do tricky things with SpecialPowers.wrap and friends (like SpecialPowers.Cc and SpecialPowers.Cu, which do an implicit .wrap()). These wrappers are intended to be a quick-and-dirty tool to frob things from mochitest-plain, but have lots of quirks that cause complicated use cases to fail in mysterious ways. Moreover, the transitive nature of the wrappers usually cause them to spread much farther than the author intended. This can waste a lot of time, and significantly reduces the value of your tests, because they're testing a complicated/magical/best-effort proxy layer rather than what we actually ship. Here are some Do's and Don'ts: Do: * Poke various privileged controls (triggered GCs, setting prefs, clearing caches) to improve the usefulness of a test. * Examine cross-origin objects to avoid complicated postMessage-based tests. Don't: * Import a framework like Task.jsm or Promise.jsm. * Implement an XPCOM component. * Interact directly with the JSM backend of a DOM API. If you find yourself itching to do something complicated, write a mochitest-chrome test. The default template [2] now generates html files (rather then XUL files), so the ergonomics there should be easier than before. If you don't want to write a mochitest-chrome test for some reason, you can also use SpecialPowers.loadChromeScript(uri), which lets mochitest-plain asynchronously load a privileged JS file in its own privileged scope. Please enforce this during review, and don't hesitate to get in touch with me if you have questions. Cheers, bholley [1] https://groups.google.com/d/msg/mozilla.dev.platform/AkX7jmLRQwg/KLqMxWLeQaYJ [2] perl testing/mochitest/gen_template.pl -type chrome -b 555555 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
