In order to prepare for out-of-process tabs, we're moving mochitest-plain tests that use UniversalXPConnect to mochitest-chrome. I've done that for the satchel tests, which mostly involved adjusting some url's, although one test, test_bug_511615, was re-factored using the framework in bug 533306. You'll need that patch in that bug to test this patch, if anyone is so inclined. All tests pass on m-c.
Created attachment 423889 [details] [diff] [review] mochitest patch v0.1
Attachment #423889 - Flags: review?
Attachment #423889 - Flags: review? → review?(gavin.sharp)
Attachment #423889 - Flags: review?(gavin.sharp) → review+
I'm not sure this is the right thing to do, but maybe I don't know the full story behind bug 533306. Basically, the issue that we should "test as you ship, ship as you test." By moving tests to mochitest-chrome (which I'm assuming is not OOP?), we violate that principle. I would think that a better approach would be to have some magic switch to allow content processes to do chrome-privileged things. That's basically the same idea as how mochitest-plain allows silent privledge escalation via netscape.security.PrivilegeManager.enablePrivilege(), which essentially doesn't work outside of the test harness.
> Basically, the issue that we should "test as you ship, > ship as you test." By moving tests to mochitest-chrome (which I'm assuming is > not OOP?), we violate that principle. There are a couple of issues here. First, I agree we should "test as you ship, ship as you test". Current mochitest-plain tests that use chrome privileges do not adhere to this principle, since normally content does not have access to chrome privileges. However, simply moving tests to mochitest-chrome doesn't address this either. There is a framework attached to bug 533306 which allows a test to be split into content and chrome parts....the content parts are where most of the "action" takes place, and it does so without directly invoking chrome privileges. Instead, when something chromish needs to be done, it sends an event to a chrome handler which takes of it. This does a much better job of allowing us to "test as you ship", since we have neither chrome masquerading as content, nor content directly using chrome. I haven't used that framework for the satchel cases, since they were simple enough I didn't need to, but perhaps you'd prefer I re-factored them using it? Second, mochitest-chrome will be as OOP as mochitest-plain. The issue wasn't to avoid OOP, but to get tests to work with it. Once OOP content is enabled, preferences will be read-only from content processes, so some adjustment is necessary for tests that currently set preferences from content.
(ok, good enough)
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
This is handled via SpecialPowers.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.