Open Bug 655622 Opened 10 years ago Updated 4 years ago
Powers for reftests to use
We should consider adding SpecialPowers to reftests. See bug 612214 comment 134.
My inclination has always been not to do this, because I want reftests to be largely something that can be used across browsers.
I understand that, but currently that means that anything that wants privileges but a reftest-style test winds up as a chrome mochitest, which is not a great fit for reftest-style testing. It also means that the tests wind up not being usable across browsers anyway. Would you feel better if we added a reftest manifest flag to enable it on a test-by-test basis? Or if we split these tests off into another set of manifests and called them "chrome reftests" or something like that? (We could do that and have the entire set of tests be loaded from chrome:// URLs, obviating the need for SpecialPowers.)
FWIW I talked to the Opera and IE guys on the SVG WG and they were for standardizing something like SpecialPowers so that we could share tests that need to do things that normal content can't. They even seemed positive about adding a pref or command line arg to turn it on in release builds (on a per domain basis) so that third parties could write/run tests and have transparency into the results in their respective implementations.
I'd be a lot more comfortable with a limited set of special powers custom-designed for reftest (and which other browsers agree should be exposed) than with the large set we expose to mochitests. (In reply to comment #2) > I understand that, but currently that means that anything that wants > privileges but a reftest-style test winds up as a chrome mochitest, which is > not a great fit for reftest-style testing. I think saying "anything" here is too strong. Some of the time, test authors realize that they don't actually need the special privilege to write the test, and they write the test another way. My point is to encourage that.
I'd like to use SpecialPowers in a reftest to use DOMWindowUtils.sendMouseEvent() instead of Element.dispatchEvent(). As far as I can see we don't invoke PresShell::HandleEvent() by dispatchEvent(). A reftest I had been trying to write in bug 1381420 needs a call of FlushThrottledStyles() which is invoked inside PresShell::HandleEvent().
You need to log in before you can comment on or make changes to this bug.