Previously we were tighly coupled with MozbuildObject. This was not in
the spirit of mach being a generic tool. Now, instead of passing multiple
arguments to __init__ of the class providing the mach command we either
pass 0 or 1. The number of arguments is detected when processing the
@CommandProvider decorator. The optional argument is a named tuple
containing mach run-time state.
Capturing of mach command provider information is now captured in a
class (as opposed to an anoymous tuple). We also capture these in a rich
data structure which is passed as part of the run-time data to the
command provider class. This allows mach commands to inspect the mach
environment.
Mach decorators have been moved to mach.decorators. mach.base is
reserved for generic mach data/container classes.
Existing mach command classes derived from MozbuildObject have been
replaced with either object or mozbuild.base.MachCommandBase. This
latter class translates the mach context instance passed to __init__
into the constructor arguments for MozbuildObject.__init__.
Support for registering function handlers with mach has been removed.
All handlers must be inside classes.
--HG--
rename : python/mach/mach/base.py => python/mach/mach/decorators.py
Before we were outright failing if the test logfile was missing when cleaning
up these tests. But that's generally a sign that the app failed to start
up properly, which is the true issue we should be trying to catch / diagnose.
Let's just print a warning here and move on.
The code interacting with the test runners now resides in closer
proximity to the code it is invoking. We also purge testing
functionality from mozbuild, which is where it never really belonged.
--HG--
rename : python/mozbuild/mozbuild/testing/reftest.py => layout/tools/reftest/mach_commands.py
rename : python/mozbuild/mozbuild/testing/mochitest.py => testing/mochitest/mach_commands.py
rename : python/mozbuild/mozbuild/testing/xpcshell.py => testing/xpcshell/mach_commands.py
It turns out that relying on the user to check return codes for every
command was non-intuitive and resulted in many hard to trace bugs.
Now most functinos just return "None", and raise a DMError when there's an
exception. The exception to this are functions like dirExists, which now return
booleans, and throw exceptions on error. This is a fairly major refactor,
and also involved the following internal changes:
* Removed FileError and AgentError exceptions, replaced with DMError
(having to manage three different types of exceptions was confusing,
all the more so when we're raising them)
* Docstrings updated to remove references to return values where no
longer relevant
* pushFile no longer will create a directory to accomodate the file
if it doesn't exist (this makes it consistent with devicemanagerADB)
* dmSUT we validate the file, but assume that we get something back
from the agent, instead of falling back to manual validation in the
case that we didn't
* isDir and dirExists had the same intention, but different
implementations for dmSUT. Replaced the dmSUT impl of getDirectory
with that of isDir's (which was much simpler). Removed
isDir from devicemanager.py, since it wasn't used externally
* killProcess modified to check for process existence before running
(since the actual internal kill command will throw an exception
if the process doesn't exist)
In addition to all this, more unit tests have been added to test these
changes for devicemanagerSUT.
The assertion encountered is:
Assertion failure: !gAppContentParents || !gAppContentParents->Get(mAppManifestURL), at ../../../dom/ipc/ContentParent.cpp:774
TEST-UNEXPECTED-FAIL | /tests/dom/browser-element/mochitest/test_browserElement_oop_CloseFromOpener.html | Exited with code 11 during test run
PROCESS-CRASH | /tests/dom/browser-element/mochitest/test_browserElement_oop_CloseFromOpener.html | application crashed (minidump found)
Thread 0 (crashed)
These are the manual fixes that the ensuing auto-generation can't deal with. Some of them
just fix up formatting (such as Components.\nFoo, so that subsequent auto-generation can
work better).
Now that window.Components is no longer acccessible to page JS, we need a way
to access it in mochitests. So this patch provides SpecialPowers.Components,
which is the bonafide Components object for the window upon which SpecialPowers
is defined. It also provides SpecialPowers.{Cc,Ci,Cr,Cu}, which are SpecialPowers-wrapped
versions of their respective sub-objects (with the exception of Ci, which is unwrapped).
If we just naively use the thread manager to dispatch the event via SpecialPowers,
we cannot avoid the XPCWrappedJS for the runnable being in chrome scope (even if
we pass a content object, we make the call in chrome scope, so we pass a cross-
compartment wrapper). This means that the machinery in
nsXPCWrappedJSClass::CheckForException ends up calling the error reporter for the
SpecialPowers scope, which isn't what we want.
Messing around with the implementation of CheckForException is playing with fire.
So we work around this with an explicit Cu API. :-(
If we just naively use the thread manager to dispatch the event via SpecialPowers,
we cannot avoid the XPCWrappedJS for the runnable being in chrome scope (even if
we pass a content object, we make the call in chrome scope, so we pass a cross-
compartment wrapper). This means that the machinery in
nsXPCWrappedJSClass::CheckForException ends up calling the error reporter for the
SpecialPowers scope, which isn't what we want.
Messing around with the implementation of CheckForException is playing with fire.
So we work around this with an explicit Cu API. :-(
