Jonathan Griffin (:jgriffin) Reporter
	Description • 15 years ago

In order to support execution on e10s, we're going to move mochitest-plain tests that use UniversalXPConnect to mochitest-chrome.  Many of these tests use UniversalXPConnect for setting preferences, and preferences will be read-only in content processes under e10s.  Most of the remaining tests use UniversalXPConnect to initiate mouse/key events with nsIDomWindowUtils, and it isn't clear whether this will still work in content processes in e10s.  To make things simple, we're just going to move all such tests to mochitest-chrome.  There are roughly 370 affected tests.

	Jonathan Griffin (:jgriffin) Reporter
	Comment 1 • 15 years ago

It turns out that doing this is not always as straightforward as I thought.  Although some tests can just be moved to mochi-chrome, with some url adjustments, others do not work with this simple treatment.  There are a class of tests, including geolocation and localstorage, for example, that require test logic to reside in a content file served from an http:// url, but which need some chrome privileges, e.g., to set preferences at multiple points during a test.

To support moving this kind of test to mochi-chrome, I've created a new "sub-framework".  This framework allows a test author to split test functionality into chrome and content parts, and allows test control to flow between the two easily.  Code on each side of the test can invoke methods on the other side, with optional callbacks.  This is done by passing custom Message Events back and forth between the two sides of the test.  The framework takes care of all the details, so test logic is minimally changed.

I've already converted many tests using this framework and it seems to be an easy approach.  Once this code is approved and checked in, I'll submit patches for all the tests that I've refactored using this mechanism.  Meanwhile, I'm attaching an example as a before/after illustration.

	(not currently active) Ted Mielczarek
	Comment 3 • 14 years ago

I don't know that I really like the complexity this entails. Do you think we can just wait and see if bug 523896 pans out in a reasonable time frame?

	(not currently active) Ted Mielczarek
	Comment 4 • 14 years ago

Comment on attachment 423630 [details] [diff] [review]
chrome-content subframework v0.1

Clearing review. If the extension approach doesn't pan out (but I think it will!) we can revisit this.

	Chris Peterson [:cpeterson]
	Comment 5 • 10 years ago

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

	Jonathan Griffin (:jgriffin) Reporter
	Comment 6 • 10 years ago

This bug is obsolete; we've addressed most of these concerns with SpecialPowers.