With this patch Marionette registers globally for the dialog notifications
and events while a session is active. Also it provides an interface for
custom dialog handlers to hook in.
Instead of the callbacks custom events could have been fired, but that would
be some more work, and should preferable be done in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D34139
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
The debug output is currently kinda polluted with lines of
received events and observer notifications. Those are not usually
needed by anyone beside us, but they also add little value in
having additional trace output, because that mainly would only
add the command and response messages.
To make debug output more helpful for our users the command
and response messages should appear here and not in trace.
But all the additional log output lines as mentioned above
we usually make use of for investigating problems should
be trace only.
Also a lot of existing debug output will remain unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D13379
--HG--
extra : moz-landing-system : lando
Replace direct invocations of Log.jsm with the new Marionette-specific
logger.
The patch also moves the Log.get() call to a lazy getter.
MozReview-Commit-ID: H1HoAgL2Cvs
--HG--
extra : rebase_source : 0e20a5c0100a359c8d8b627457fc178293387078
Until now Marionette assumed that the events `TabClose` and `unload`
indicate that a top-level browsing context or chrome window has been
closed. But both events are fired when the browsing context or chrome
window is about to close. As such a race condition can be seen for
slow running builds.
To clearly wait until the top-level browsing context or chrome window
has been closed, the appropriate message manager needs to be observed
for its destroyed state.
MozReview-Commit-ID: DCdaIiULqey
--HG--
extra : rebase_source : f5659c1aa640d5265240bb1c4fe2059fb46d3cac
Until now Marionette assumed that the events `TabClose` and `unload`
indicate that a top-level browsing context or chrome window has been
closed. But both events are fired when the browsing context or chrome
window is about to close. As such a race condition can be seen for
slow running builds.
To clearly wait until the top-level browsing context or chrome window
has been closed, the appropriate message manager needs to be observed
for its destroyed state.
MozReview-Commit-ID: DCdaIiULqey
--HG--
extra : rebase_source : 3f9248ebbdc696ce5e6856ecb167ab144739a52e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Whenever we make proxied IPC calls to the content frame's message manager,
we do so over the global message manager. AsyncMessageChannel takes a
closure that returns the current message manager from GeckoDriver#mm,
but this is unnecessary because it always holds a global message channel.
By not having to pass in a closure returning a message manager
to AsyncMessageChannel we losen the tight coupling a little bit.
Future patches will further reduce the tight coupling of browserFn.
MozReview-Commit-ID: EU0pkxA7lab
--HG--
extra : rebase_source : f6d6735e2d5bacdfbf20bde9a835f3f83846b2d6
The uuid-generator is not always used when the proxy module is imported.
This changes it to be lazily loaded so we do not always initialise it.
MozReview-Commit-ID: In0oAGDFjWy
--HG--
extra : rebase_source : d4d6c594cd1ac0872a1f34a30f3e7452a7759300
The SyncChromeSender class and its factory construction function
proxy.toChrome is not used in Marionette and can be safely removed.
MozReview-Commit-ID: jBJ0nIkn3i
--HG--
extra : rebase_source : 83d9c8261eafc9385d8edee913cc0fdfed48dcaa
The AsyncChromeSender and its factory construction function
proxy.toChromeAsync are no longer in use.
MozReview-Commit-ID: 8tFr1IUTd5g
--HG--
extra : rebase_source : 0ade57fd83aa7d38b93f22cc87952e004902995d
Instead of having commands serialising their own JSON-safe messages
when communicating with the content frame script, this patch changes
the AsyncMessageChannel to use evaluate.toJSON.
MozReview-Commit-ID: LmAVGEjqMTB
--HG--
extra : rebase_source : 7f39cccc1468217a8a6bcf107241fd5648cb24d2
Various fixes to make the generated API documentation from
testing/marionette somewhat easier to read.
MozReview-Commit-ID: F9duuQoOYBt
--HG--
extra : rebase_source : 3ade69773ceba42826aedef05b1371240b51cf82
Instead of importing everything from the testing/marionette/error.js
module into the global scope, we need to be selective about what symbols
we want.
MozReview-Commit-ID: HZDAS0bs0GD
--HG--
extra : rebase_source : 14a300bb2cedc0716168d50846755a6faed83012
In some cases the click command can trigger the closing of the
currently selected tab or window. To not cause a hang when waiting
for a response from the removed framescript, the tab and window
closing events have to be observed. Also the command has to return
immediately.
MozReview-Commit-ID: 9WeXryrKEJr
--HG--
extra : rebase_source : a7a23cf19e55eecbf957d48c2182a601d63d0909
In some cases the click command can trigger the closing of the
currently selected tab or window. To not cause a hang when waiting
for a response from the removed framescript, the tab and window
closing events have to be observed. Also the command has to return
immediately.
MozReview-Commit-ID: 9WeXryrKEJr
--HG--
extra : rebase_source : 682d67d51109c57a6de1a129492ebb5b635d7c56
Since bug 1326534 we have discarded the original stacktrace from errors
originating inside Marionette. This was due to faulty logic when
attempting to generate a new stacktrace when it was missing from a
propagated error.
This change simplifies WebDriver errors by making use of Error
inheritance. The WebDriver error specific functions error.toJson and
error.fromJson has additionally been moved to WebDriverError.
MozReview-Commit-ID: C3Ns0H01LyG
--HG--
extra : rebase_source : 0c705054dae8c0647500bb90e9b970cc57e712c4
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
--HG--
extra : rebase_source : 38cc7b1e374fd42afb213133fd1a5e11bf8bdd95
error.wrap acts as a no-op if it is passed a prototype which is already
of the WebDriverError prototypal chain.
MozReview-Commit-ID: Gd9kUEvsgNv
--HG--
extra : histedit_source : a6e620e3e4b6bfa4e1d77df48eaab59ffbc3cdce
extra : rebase_source : a94ae7fff63530a4cc4d1875bb4894657834ecb0
extra : commitid : HObqpKV7a9s
extra : source : d75ad1397656e43d22d0d69211df9fce3a667f0d
extra : intermediate-source : eff85dc0eaa9da4c4dff306cdb9a7474df29ccf1
error.wrap acts as a no-op if it is passed a prototype which is already
of the WebDriverError prototypal chain.
MozReview-Commit-ID: Gd9kUEvsgNv
--HG--
extra : commitid : HObqpKV7a9s
extra : rebase_source : c96b3c1a00a68a56d69d253945de5607039e3b49
extra : source : d75ad1397656e43d22d0d69211df9fce3a667f0d
extra : histedit_source : a6e620e3e4b6bfa4e1d77df48eaab59ffbc3cdce