Various fixes to make the generated API documentation from
testing/marionette somewhat easier to read.
MozReview-Commit-ID: F9duuQoOYBt
--HG--
extra : rebase_source : 3ade69773ceba42826aedef05b1371240b51cf82
When linting the Marionette server code,
https://searchfox.org/mozilla-central/commit/de001d80b777ff0fcfa823a52e8d49b4981af040
accidentally removed the missing window check from the
Marionette:GetWindowRect command. This change reintroduces the
check that was accidentally removed.
MozReview-Commit-ID: FkDOUKR2dIi
--HG--
extra : rebase_source : abc32aec9b005f341d1e1deb1bbc9a3132dd35cb
baseURI isn't actually we have to check for to get the
current documents URI. Therefore documentURI exists.
MozReview-Commit-ID: CDhOZ8lU2qJ
--HG--
extra : rebase_source : c53f79468a7d319bd5e7aa40338fce0ca7299bd4
With multi-processes for content reloads of the frame script
can happen at any time, and not only for remoteness changes.
As such the current browser has to be re-registered with the
new id of the listener.
MozReview-Commit-ID: 48MOZfuPTR9
--HG--
extra : rebase_source : 60e91ae7e1cdc942d0ac9a9dd3aac3baeccc5ddf
This wrapper just calls back into the MarionetteDriver, and
doesn't have any value. Removing it simplifies the call stack.
MozReview-Commit-ID: GH1xUHX12Xi
--HG--
extra : rebase_source : a3b9e57e63809c9936fdb2686ad6016339ea7bf7
By not using the JSON format when sending the capabilities to the
frame script, the values cannot be correctly decoded. As result
the capabilities will be reset to their default values for the
listener, and can cause various failures.
MozReview-Commit-ID: KaryoJiyd30
--HG--
extra : rebase_source : 206e45755d3ea9b6cbf2f2022a9a364dcf22d78e
To retrieve the title of the currently selected content browser
it is not necessary to call into the frame script. Instead just
take the value from the parent process directly.
MozReview-Commit-ID: KEpYKLIydrJ
--HG--
extra : rebase_source : 8b179de7057f8655a81656bd4d95b1562edb9f54
getContext and setContext are duplicated further up under the Marionette
serivce entries.
MozReview-Commit-ID: 2V5S2XG6wDw
--HG--
extra : rebase_source : 1f22adc294c063f014e3a0e884a01ed6a7fbe43e
In particular, XPCNativeWrapper should probably be made available
by default.
MozReview-Commit-ID: E1oYFyApbLi
--HG--
extra : rebase_source : 4e27ad6882bd4e43dadc97d4fd2a186e01510dfd
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
The quitApplication command was accidentally removed in 1e96a289d28a.
This adds it back as a recognised command alias in order to not break
geckodriver.
MozReview-Commit-ID: IZ0h8dv9ILt
--HG--
extra : rebase_source : 61550dae3a71973a2028d6384bc3eab388c17c21
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
This adds commands to start a reftest session, run a test, and end the
session. It as assumed that after you start a reftest session you will
just run reftests until you end the session. When starting a session
the user provides a string indicating when screenshots should be
taken, and an object mapping urls to a count of the number of times
that url is expected to be used in the session, to help with
caching. Running the tests takes a url to a test, an expected status,
a timeout, and a nested list of possible references, in which each
entry at a specific level is combined by OR and nested references are
combined by AND.
The implementation is heavilly inspired by the existing reftest
harness, starting a minimal window with no tabs, and loading the urls
directly in there. In order to get a screenshot in the e10s case we
have to pass the DRAW_VIEW and USE_WIDGET_LAYERS flags when taking the
screenshot.
For performance we heavily cache canvases; for references that will be
repeated we cache the full canvas with image, and we also cache a
single canvas to use for all other screenshots to avoid the overhead
of repeatedly creating a new canvas element.
MozReview-Commit-ID: JOFvtmH7tg
Because this window is a normal Firefox window but doesn't contain any
tabs, the normal Marionette functions for iterating over windows don't
work well. As a sort of hack, identify this window by the id of its
root element, and special case it when finding windows in Marionette.
MozReview-Commit-ID: LxPv13YDXDu
This allows other commands to implicitly change the window handle, by
calling findWindow with appropriate arguments to get a window
properties object and then passing that to setWindowHandle.
MozReview-Commit-ID: 4NpYxjsMM4T
This adds commands to start a reftest session, run a test, and end the
session. It as assumed that after you start a reftest session you will
just run reftests until you end the session. When starting a session
the user provides a string indicating when screenshots should be
taken, and an object mapping urls to a count of the number of times
that url is expected to be used in the session, to help with
caching. Running the tests takes a url to a test, an expected status,
a timeout, and a nested list of possible references, in which each
entry at a specific level is combined by OR and nested references are
combined by AND.
The implementation is heavilly inspired by the existing reftest
harness, starting a minimal window with no tabs, and loading the urls
directly in there. In order to get a screenshot in the e10s case we
have to pass the DRAW_VIEW and USE_WIDGET_LAYERS flags when taking the
screenshot.
For performance we heavily cache canvases; for references that will be
repeated we cache the full canvas with image, and we also cache a
single canvas to use for all other screenshots to avoid the overhead
of repeatedly creating a new canvas element.
MozReview-Commit-ID: JOFvtmH7tg
--HG--
extra : rebase_source : ab5a2ef2e450b9bbdc6bc3c9487ed5dfda2c1d4b
Because this window is a normal Firefox window but doesn't contain any
tabs, the normal Marionette functions for iterating over windows don't
work well. As a sort of hack, identify this window by the id of its
root element, and special case it when finding windows in Marionette.
MozReview-Commit-ID: LxPv13YDXDu
--HG--
extra : rebase_source : 8c0aa7a4aeff69e1d7c86ba7cbb6c421abd0c31d
This allows other commands to implicitly change the window handle, by
calling findWindow with appropriate arguments to get a window
properties object and then passing that to setWindowHandle.
MozReview-Commit-ID: 4NpYxjsMM4T
--HG--
extra : rebase_source : 9b53d8b10e2341624c3add5e9975aab47e0b320f
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
The cookie service relies on the current document's
domain which is accessible from chrome space through
this.curBrowser.contentBrowser.contentURI.host.
As it is implemented currently, Marionette's cookie service jumps
between chrome- and content space more than necessary. This incurs
significant serialisation and IPC overhead, considering that the domain,
hostname, and current path information is readily available in chrome
space.
This patch removes all cookie-related functionality from
testing/marionette/listener.js, and implements a pure chrome-only
version of the service. It does, however, not try to fix conformance
issues with the WebDriver specification, of which there are many.
Some of the algorithms, especially to do with iteration over cookies,
implemented in cookie.iter, is also highly suboptimal. I have not
fundamentally changed any algorithms, and so my recommendation is to
address this later when addressing potential conformance bugs.
MozReview-Commit-ID: Fgs8ocbDJxb
--HG--
extra : rebase_source : 16470d5341459e40b1ceed12728451d517bbc490
Instead of returning a string representation of the current locaton from
GeckoDriver#currentURL, we encode it as a URL object.
browser.Context#currentURL is also renamed to currentURI to reflect that
it now returns an nsIURI object.
The motivation behind this change is that we need to access a URL's port,
protocol, pathname, and hostname separately.
MozReview-Commit-ID: DM7gkrHhFpb
--HG--
extra : rebase_source : 1c8c3535bebc1e91a7f8ddaa88278cc78f66cf56
We want to namespace the WebDriver commands so that we in the future can
use Marionette without activating the WebDriver functionality. Today,
Marionette sets up a lot of state which is not needed if the client only
needs Marionette for installing an addon.
Namespacing the WebDriver commands is the first step towards a future
where features can be enabled and disabled at runtime.
MozReview-Commit-ID: E2lAGKb833F
--HG--
extra : rebase_source : 2d72274e4d85506f3af319e2ca36600128faa6f6
We don't want to support multiple namespaces in service endpoints as it
will add unecessary complexity when we in the future support enabling-
and disabling services on an individual level. This patch drops the
"localization" namespace and exposes "L10n:*".
MozReview-Commit-ID: IhqG72vMohJ
--HG--
extra : rebase_source : 9d675e2915f8ae25bcc9fdedab3e2095038990f0
The Marionette service provides commands that are specific to Marionette
operation, such as setting the target (context) for all other commands,
deciding whether to accept new connections, and quitting the browser.
MozReview-Commit-ID: 7NIbaAUzybx
--HG--
extra : rebase_source : c46395d87fb60214a9bd434e71dd2d622f050d91
The "timeouts" command could have been removed in Firefox 55, and
"quitApplication" can be removed with Firefox 56.
MozReview-Commit-ID: Fe7x8Yy0vSb
--HG--
extra : rebase_source : fc8b2c3c27f76a472cbdd8681efff06ca60e00f7
The getMarionetteID, sayHello, and setTestName commands are not
implemented but defined in the command list.
MozReview-Commit-ID: 7Yzgrp9qpeX
--HG--
extra : rebase_source : e34d2ef599525b3fc751a43a6edcd917a72b6725
The expires property on nsICookie2 does not exist and we are
consequently returning it as undefined, which gets omitted in the JSON
serialisation to the client.
This patch changes it to return the correct property so that the expiry
property is returned as part of the serialised cookie.
MozReview-Commit-ID: IIjf4NWnUoQ
--HG--
extra : rebase_source : 5e2dc27fb550a010dcbe40eee49d9ae31244d749
The Marionette setWindowRect command is meant to provide a blocking API
for resizing and moving the window. This currently has an intermittent
rate of ~0.254 with the WPT conformance test.
The main issue in providing a blocking API is that the DOM resize
event fires at a high rate and needs to be throttled. We are able to
throttle this successfully with requestAnimationFrame, and before that,
a hard-coded 60 fps setTimeout delay. To the naked eye, this appears to
synchronise window resizing before returning the resposne to the client.
However, occasionally the response contains the wrong window size.
window.outerWidth and window.outerHeight do not appear to be
deterministic as DOM properties are not synchronously populated.
Calls to ChromeWindow.outerWidth and ChromeWindow.outerHeight sometimes
also returns inconsistent values. Tests, document in the bug, have
shown that somtimes, the returned window size from the setWindowRect
command is correct, and that the size from the subsequent getWindowRect
command is not.
By using a combination of Services.tm.mainThread.idleDispatch and a
blocking promise on not returning a response until the window size has
changed, we are able to reduce the intermittent rate significantly (by
over an order of magnitude).
As one would expect, delaying computation allows DOM property values to
populate, and as such does not address the underlying problem or make it
inconceivable that the race described above could re-appear, but it does
seem to be more reliable than the current approach.
MozReview-Commit-ID: Lf2yeeXH082
--HG--
extra : rebase_source : e27912fdcb6edbf825bf3168f3542ff2b4551b8b
We need to delay the response from the setWindowRect command until the
window has had time to properly resize. But because the DOM resize
event is not synchronous, we cannot rely on it alone to tell us when the
widget toolkit has actually completed the resizing.
To overcome this problem we throttle the event using
ChromeWindow.requestAnimationFrame to force the event loop to flush
before resolving the promise.
The setWindowRect command previously relied on a 15 FPS setTimeout delay
because requestAnimationFrame did not work with ChromeWindow, but this
seems to have since been fixed. Local tests show that this approach is
more stable and produces less intermittent results.
MozReview-Commit-ID: D1ICb3F6vX3
--HG--
extra : rebase_source : ef5ef15db80ce78284672551581ce5d9cdde9189
Chrome window handles and window handles are identifiers for different types
of windows. As such those should not be mixed up. Especially for chrome
windows without a tabbrowser we erroneously inject such a chrome window
handle. It can break those tests which assume it's a tab.
MozReview-Commit-ID: 1n2vOyfaSUh
--HG--
extra : rebase_source : 08ebff867a0075191908bc7aa535f3f8b386871d
We need to delay the response from the setWindowRect command until the
window has had time to properly resize. But because the DOM resize
event is not synchronous, we cannot rely on it alone to tell us when the
widget toolkit has actually completed the resizing.
To overcome this problem we throttle the event using
ChromeWindow.requestAnimationFrame to force the event loop to flush
before resolving the promise.
The setWindowRect command previously relied on a 15 FPS setTimeout delay
because requestAnimationFrame did not work with ChromeWindow, but this
seems to have since been fixed. Local tests show that this approach is
more stable and produces less intermittent results.
MozReview-Commit-ID: D1ICb3F6vX3
--HG--
extra : rebase_source : 786fe9843f2cbc29e4708dd8db279fd4a273fe51
We need to delay the response from the setWindowRect command until the
window has had time to properly resize. But because the DOM resize
event is not synchronous, we cannot rely on it alone to tell us when the
widget toolkit has actually completed the resizing.
To overcome this problem we throttle the event using
ChromeWindow.requestAnimationFrame to force the event loop to flush
before resolving the promise.
The setWindowRect command previously relied on a 15 FPS setTimeout delay
because requestAnimationFrame did not work with ChromeWindow, but this
seems to have since been fixed. Local tests show that this approach is
more stable and produces less intermittent results.
MozReview-Commit-ID: D1ICb3F6vX3
--HG--
extra : rebase_source : 90dba4abf64c820b11e1edb5e0e96133cbcfa76a
Multiple commands rely on the current URL of the chrome window, or
the active content browser. The newly added properties help to ease
the retrieval of the URL for both chrome and content scope.
MozReview-Commit-ID: 2KAtRzHxxNc
--HG--
extra : rebase_source : 85e4192f8a01fe4e1735f7812612decba0db1ad5
When accessing a property of the current content browser from
the parent process, the current top-level browsing context has
to be valid.
MozReview-Commit-ID: BZHJTk1j5Nj
--HG--
extra : rebase_source : 7e44fc6e05d7fb1429fb3e36e897cf51b3d9142f
Andreas Tolfsen
Henrik Skupin
James Graham
Wes Kocher
Ryan VanderMeulen
Phil Ringnalda
Andreas Farre
Andreas Tolfsen
Sebastian Hengst