This lays the foundation for Marionette to work inside
GeckoView-consuming Apps.
Differential Revision: https://phabricator.services.mozilla.com/D17578
--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 window should always be restored first to the normal window state,
before a special state like fullscreen or minimized can be entered.
Right now this isn't done when going from a maximized window into
fullscreen mode, or when minimizing the window.
Differential Revision: https://phabricator.services.mozilla.com/D17472
--HG--
extra : moz-landing-system : lando
Marionette should do its best to get the browser into the requested
window state, but if it is not possible to do so, it shouldn't raise
a timeout error. This is mostly the case when running tests under
xvfb with no window manager running. Instead we just log the
message for further investigation.
Further the timeout value has to be set to a value which wouldn't
cause the commands to inappropriately fail due to animations, or
a slow machine.
Differential Revision: https://phabricator.services.mozilla.com/D17144
--HG--
extra : moz-landing-system : lando
To detect when the window got minimized usally "visibilitychange" events
are fired to the content window. The "WebDriver:MinimizeWindow" command
has to wait for those.
Depends on D16096
Differential Revision: https://phabricator.services.mozilla.com/D16098
--HG--
extra : moz-landing-system : lando
By default PollPromise has to behave similar to a normal Promise
and wait forever until it gets resolved or rejected.
Depends on D13662
Differential Revision: https://phabricator.services.mozilla.com/D15907
--HG--
extra : moz-landing-system : lando
By default PollPromise has to behave similar to a normal Promise
and wait forever until it gets resolved or rejected.
Depends on D13662
Differential Revision: https://phabricator.services.mozilla.com/D15907
--HG--
extra : moz-landing-system : lando
On certain window manager configurations a window may be resized
to fit the full available dimensions of the screen without going
into the maximised state. Similarily, a maximised window may be
the exact dimensions of the screen.
If the window outerWidth/outerHeight is 800x600 and in maximised
state, resizing it to 800x600 through WebDriver:SetWindowRect will
not work because the window has already reached its requested dimensions.
This patch ensures to wait for the resizeEnd event when the window
state is not normal.
Depends on D8419
Differential Revision: https://phabricator.services.mozilla.com/D10568
--HG--
extra : moz-landing-system : lando
This requests an animation frame off ChromeWindow and waits for
the main thread's event queue to become idle in relation to window
manipulation commands.
It additionally clears the event queue before resizing, because
this is a particularly hazardous operation. We don't know the
exact science as to why this is needed, so it may just be that this
introduces enough latency for the operation to complete successfully.
File this under "secret sauce".
This ensures all potential synchronisation code between e.g. the
parent process and the child processes have had time to run before
we return from WebDriver:{MinimizeWindow,MaximizeWindow,FullscreenWindow}.
Depends on D8418
Differential Revision: https://phabricator.services.mozilla.com/D8419
--HG--
extra : moz-landing-system : lando
My delegating to the main thread, waiting for the last DOM resize event
to fire, and requesting an animation frame from the ChromeWindow, we
can ensure the window is (more) synchronously resized. This ensures
better reliability when setting a window's dimensions.
All this means we can get rid of the heuristics we use for "waiting
for a window resize" to occur by checking if the outerWidth/outerHeight
has changed. These were obviously bug ridden.
Depends on D8417
Differential Revision: https://phabricator.services.mozilla.com/D8418
--HG--
extra : moz-landing-system : lando
When the ChromeWindow is already in the desired x/y position,
WebDriver:SetWindowRect should act as a no-op. This avoids a
superfluous call to ChromeWindow.moveTo.
Depends on D8416
Differential Revision: https://phabricator.services.mozilla.com/D8417
--HG--
extra : moz-landing-system : lando
win.Maximized does not exist. This should be WindowState.Maximized.
Depends on D8415
Differential Revision: https://phabricator.services.mozilla.com/D8416
--HG--
extra : moz-landing-system : lando
Unlike the visibilitychange event, sizemodechange appears to fire in a
mostly reliable way. However, in the off-chance that sizemodechange
should not fire, we need an escape path so that Marionette returns
within a timely fashion.
Depends on D8414
Differential Revision: https://phabricator.services.mozilla.com/D8415
--HG--
extra : moz-landing-system : lando
The visibilitychange DOM event does not fire reliably in all
configurations when retrieved from web content. It appears to fire more
reliably in chrome, but to ensure a call to WebDriver:MinimizeWindow
never hangs, we additionally change it to be a TimedPromise.
There is an assumption here that if the iconification process does
not complete within this duration, there is nothing we can do.
Depends on D8413
Differential Revision: https://phabricator.services.mozilla.com/D8414
--HG--
extra : moz-landing-system : lando
Instead of waiting for the visibilitychange event to fire, which does
not work in headless mode, we can poll ChromeWindow.windowState which
appears to be a more reliable way of telling the window's current state.
This will resolve the problem where Marionette never returns from
restoration due to visibilitychange never firing, and will additionally
make it more reliable.
Depends on D8412
Differential Revision: https://phabricator.services.mozilla.com/D8413
--HG--
extra : moz-landing-system : lando
With the use of multiple content processes in Firefox a navigation
command can cause the active framescript to be moved to a different
process. This interrupts the currently executed command, and as such
needs to be executed again after the framescript has been finished
initializing.
Currently flushing the pending commands doesn't take into account
that the framescript can even be moved multiple times to a different
process during a single page navigation. As such all pending commands
are getting removed after the first process move. For navigation
commands this means that no page load listeners are attached for
subsequent process changes, and navigation commands could never
return, and cause a hang of Marionette.
To solve the problem the pending commands need to be flushed each
time the process changes. They will remove themselves from the list
once they have finished processing.
Depends on D10998
Differential Revision: https://phabricator.services.mozilla.com/D10999
--HG--
extra : moz-landing-system : lando
This removes a series of deprecated Marionette commands following
a big naming scheme change a while back. These commands could have
safely been removed since Firefox 63.
singleTap and acceptConnections were still in use in the Marionette
Python client, so they can only be removed in Firefox 66 at the
earliest.
WebDriver:AcceptDialog is used by geckodriver, which means it would
have to drop support for Firefox 57 in order to change to use
WebDriver:AcceptAlert. Marking this as deprecated, but used in
geckodriver for now.
Depends on D10836
Differential Revision: https://phabricator.services.mozilla.com/D10837
--HG--
extra : moz-landing-system : lando
This patch changes Marionette to only run the interactability test
on <input type=file> when the strictFileInteractability capability is set.
strictFileInteractability is not set by default which means
this changes WebDriver:SendElementKeys' behaviour to not run
interactability checks on <input type=file>. This aligns our
WebDriver implementation with the current behaviour in Chrome.
To make it legible what the input to interaction.sendKeysToElement
is, its API has changed to take an options dictionary instead of
three boolean arguments at the end.
Depends on D10274
Depends on D10274
Differential Revision: https://phabricator.services.mozilla.com/D10275
--HG--
extra : moz-landing-system : lando
This patch changes Marionette to only run the interactability test
on <input type=file> when the strictFileInteractability capability is set.
strictFileInteractability is not set by default which means
this changes WebDriver:SendElementKeys' behaviour to not run
interactability checks on <input type=file>. This aligns our
WebDriver implementation with the current behaviour in Chrome.
To make it legible what the input to interaction.sendKeysToElement
is, its API has changed to take an options dictionary instead of
three boolean arguments at the end.
Depends on D10274
Differential Revision: https://phabricator.services.mozilla.com/D10275
--HG--
extra : moz-landing-system : lando
Provides specific error messages informing the user what action
was taken with the user prompt, based on the configuration of the
unhandled prompt handler.
Differential Revision: https://phabricator.services.mozilla.com/D10089
--HG--
extra : moz-landing-system : lando
This patch moves the private whenIdle function to sync so it can
be shared across JSMs.
It also changes its semantics somewhat, so that instead of taking
a callback function (suitable for DOM event callbacks) it returns
a promise that is resolved when the main thread becomes idle and
the window has completed an animation frame tick.
This patch moves the private whenIdle function to sync so it can
be shared across JSMs.
It also changes its semantics somewhat, so that instead of taking
a callback function (suitable for DOM event callbacks) it returns
a promise that is resolved when the main thread becomes idle and
the window has completed an animation frame tick.
Nick Alexander
Myk Melez
Kris Maglione
Henrik Skupin
Geoffrey Sneddon
Cosmin Sabou
Brindusan Cristian
Andreas Tolfsen
Geoff Lankow
Ciure Andrei
arthur.iakab