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.
To allow the focusmanager testmode to raise focus events even with
the Firefox window in the background, the current chrome window has
to be virtually brought into foreground. This should be at least
always done when creating a new session.
--HG--
extra : rebase_source : f080d6e85f0b3d68b8ce99ece9bb9e975806f50a
When switching between chrome windows Marionette doesn't update
its references for the mainFrame (current chrome window) and
curFrame (current frame inside the chrome window). Instead it
gets currently only updated when a new chrome window opens.
It means that in most cases Marionette sets the focus on the
wrong chrome window and frame.
--HG--
extra : rebase_source : 3aebd6a15e46f183b32f4d7cf6727ef6c370f6f3
Two cases were hiding permanently failing tests. I've commented those out and
filed bug 1487431.
Differential Revision: https://phabricator.services.mozilla.com/D4680
--HG--
extra : rebase_source : 232fa6173de8844a9c47d59926ec8e39d0640ecd
Workaround until we have a sane dynamic user prompt implementation
(see bug 1477977). At least for now this patch will give us the
opportunity to handle multiple open user prompts.
--HG--
extra : rebase_source : 4a242daef46287051fc6be4c4d9353046d0f6559
Both "WebDriver:AcceptAlert" and "WebDriver:DismissAlert" have to
wait until the tab modal dialog has been closed.
--HG--
extra : rebase_source : 64742b03faa900fe301a684a17666e3366322f5b
