зеркало из https://github.com/mozilla/gecko-dev.git
31755b431d
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development. Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074. Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly. Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner. Differential Revision: https://phabricator.services.mozilla.com/D86255 |
||
|---|---|---|
| .. | ||
| actors | ||
| chrome | ||
| client | ||
| components | ||
| doc | ||
| harness | ||
| test | ||
| .eslintrc.js | ||
| README | ||
| accessibility.js | ||
| action.js | ||
| addon.js | ||
| assert.js | ||
| atom.js | ||
| browser.js | ||
| capabilities.js | ||
| capture.js | ||
| cert.js | ||
| cookie.js | ||
| dom.js | ||
| driver.js | ||
| element.js | ||
| error.js | ||
| evaluate.js | ||
| event.js | ||
| format.js | ||
| interaction.js | ||
| jar.mn | ||
| l10n.js | ||
| legacyaction.js | ||
| listener.js | ||
| log.js | ||
| mach_commands.py | ||
| mach_test_package_commands.py | ||
| message.js | ||
| modal.js | ||
| moz.build | ||
| navigate.js | ||
| packets.js | ||
| prefs.js | ||
| print.js | ||
| proxy.js | ||
| reftest.js | ||
| reftest.xhtml | ||
| server.js | ||
| stream-utils.js | ||
| sync.js | ||
| transport.js | ||
| wm.js | ||
README
Marionette [ ˌmarɪəˈnɛt] is * a puppet worked by strings: the bird bobs up and down like a marionette; * a person who is easily manipulated or controlled: many officers dismissed him as the mayor’s marionette; * the remote protocol that lets out-of-process programs communicate with, instrument, and control Gecko-based browsers. Marionette provides interfaces for interacting with both the internal JavaScript runtime and UI elements of Gecko-based browsers, such as Firefox and Fennec. It can control both the chrome- and content documents, giving a high level of control and ability to replicate, or emulate, user interaction. Head on to the Marionette documentation to find out more: https://firefox-source-docs.mozilla.org/testing/marionette/marionette/