This will only work if runByManifest is enabled, otherwise the harness will error out. It's also
illegal to set this on an individual test, it must be on the entire manifest.
MozReview-Commit-ID: LWYa3Sk1uyW
--HG--
extra : rebase_source : ea4add087c795324745a0a5fc18b3ef50b2292b0
Changes were made to the SpawnTask.js file, which is where the add_task
implementation lives for this API.
MozReview-Commit-ID: 7bPlcrrJkCi
--HG--
extra : rebase_source : ce14fda2e71508d3e9dea39ad62e65a57b432779
.skip() allows you to skip a specific task from running and .only() allows you
to focus on only one specific task.
MozReview-Commit-ID: 36qQOhICN7s
--HG--
extra : rebase_source : 4b8e15a65dd9370b87dfdba8c85c64aae76dd4a0
This also starts running the selftests on linux debug builds, since that's the only place that we
can test assertions and leaks.
MozReview-Commit-ID: JTdTLOLWn5r
--HG--
extra : rebase_source : 340aca0c4e5f9697b1d652fd192332e47a1acab9
extra : histedit_source : 2d4b542d2122b4c6d2d48fc9c49848d5453e4533
The mochitest harness uses testEnd multiple times to log various failures. This can result
in several testEnd messages, which will soon cause mozlog to spit out an error. Instead,
these should be testStatus.
This also starts using mozlog's assertion_count log action to log test assertions (again,
instead of testEnd).
MozReview-Commit-ID: FFsyicSso5Y
--HG--
extra : rebase_source : 5e8d02714fcf24f2b86a9867b0403bbda0d00f91
This also adds a utility function for synthesizing native touch
events to Eventutils.js.
I did not add a test for searchbar because of intermittent issues
with showing the contextmenu (that are not reproducible manually).
I believe this is rather related to searchbar functionality than
my patches.
MozReview-Commit-ID: Dqm92Saosxz
--HG--
extra : rebase_source : e59df4f487f60cea137fbf8aea71a854a5706de9
This also adds a utility function for synthesizing native touch
events to Eventutils.js.
I did not add a test for searchbar because of intermittent issues
with showing the contextmenu (that are not reproducible manually).
I believe this is rather related to searchbar functionality than
my patches.
MozReview-Commit-ID: Dqm92Saosxz
--HG--
extra : rebase_source : d5c4333609b68773e62447bd3158cadfa89b803b
SpecialPowers.loadChromeScript() sends a script to the child process,
then creates a sandbox, and runs the script in that sandbox. There are
various sandboxOptions that can be passed when creating a sandbox, and
it would be nice to have that functionality for loadChromeScript.
I just need this for wantGlobalProperties, but I might as well make it
as general as possible. I'm not sure all of the types it can take can
actually be serialized across processes, but I guess that's okay.
MozReview-Commit-ID: GoJjXdjizFk
--HG--
extra : rebase_source : 9c2bc190dbf5a080978953cffd64205e8b816367
This will create a mochitest selftest harness based on |mach python-test|. There
is also a basic test that checks whether TEST-PASS and TEST-UNEXPECTED-FAIL work.
MozReview-Commit-ID: Jqyhbj7nC6z
--HG--
extra : rebase_source : d73b37305590a415e350ee45785a85635e7d4209
The browser-chrome self-test files now use the setExpectedFailuresForSelfTest function to specify the exact number of assertion failures that will be triggered. Also, most failures are now intercepted when specifying the "fail-if" property in a "browser.ini" manifest, while previously only those triggered using the "ok" function were intercepted. This allows re-enabling several browser-chome self-tests.
MozReview-Commit-ID: DlDjWaJPfvH
--HG--
extra : rebase_source : d9977dac6ecbd2b28f5697d22ce6edf4e1d4f899
extra : source : 6da58c7bb247d3e879012bea8d848eb68f16e36e
The browser-chrome self-test files now use the setExpectedFailuresForSelfTest function to specify the exact number of assertion failures that will be triggered. Also, most failures are now intercepted when specifying the "fail-if" property in a "browser.ini" manifest, while previously only those triggered using the "ok" function were intercepted. This allows re-enabling several browser-chome self-tests.
MozReview-Commit-ID: DlDjWaJPfvH
--HG--
extra : rebase_source : 498914c84ab69dd484fb5487ad9967073c331fd3
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
This patch allows the use of the flag '--jscov-dir-prefix' for mochitest plain tests to enable code coverage collection with the JS Debugger. It also enables the mochitest-plain tests for the linux64-jsdcov build platform.
MozReview-Commit-ID: 6RqMEZ1I0D7
--HG--
extra : rebase_source : 351754541801f69f7c54807f6bdd3a3d1baf9222