Two mozconfg additions are necessary for these jobs on linux:
1.) Turning off the clang plugin, which will not get built during these builds
and will cause failures when C/C++ needed by the rust build tries to find it.
2.) Adding --output-sync=line to our make invocation: at some point the
"export" phase started relying on this, and it's missing because the
non-default build targets invoked by the rusttests builds don't go through
client.mk.
Differential Revision: https://phabricator.services.mozilla.com/D11242
--HG--
extra : moz-landing-system : lando
Reasons for doing this:
(1) Bug 1501316 becomes easier to fix.
(2) JSOP_TABLESWITCH is no longer a variable-length bytecode op so we can get
rid of js::GetVariableBytecodeLength.
Depends on D11018
Differential Revision: https://phabricator.services.mozilla.com/D11019
--HG--
extra : moz-landing-system : lando
The Maximize Window command's stress test is broken on Windows due
to a socket problem on Windows specifically. I think the problem
is that the socket buffer is too small because of a very intensive
check for the window size not changing.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1505806 for more details.
Differential Revision: https://phabricator.services.mozilla.com/D11331
--HG--
extra : moz-landing-system : lando
Parsing prefs and env on the command line is a common task performed by our harnesses, let's
move it into mozbase.
Depends on D9717
Differential Revision: https://phabricator.services.mozilla.com/D9796
--HG--
extra : moz-landing-system : lando
The things that rely on TimedPromise, such as awaiting a sizemodechange
event on exiting fullscreen, takes a lot longer to perform in Asan
and debug builds than in optimised builds.
This patch increases the TimedPromise timeout duration by three
times in debug builds, which is the same amount WPT uses.
Depends on D10569
Differential Revision: https://phabricator.services.mozilla.com/D11189
--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
This adds a new synchronisation primitive to Marionette which will
allow us to wait for the last in a sequence of events to fire.
This is especially useful for high-frequency events such as the DOM
resize event, where multiple resize events may fire as the window
dimensions are being changed.
Depends on D8411
Differential Revision: https://phabricator.services.mozilla.com/D8412
--HG--
extra : moz-landing-system : lando
On some systems and window managers, such as macOS and when X11
forwarding an application across systems, there exists a 22px
window border that we cannot detect or do anything about. As this
test is to verify that the width/height changed beyond 800x600,
this assertion change should make the tests pass on more configurations.
Depends on D8409
Differential Revision: https://phabricator.services.mozilla.com/D8410
--HG--
extra : moz-landing-system : lando
Quering the stored devices list for an ID was not always correct. The stored devices list is expected to be empty before an enumeration takes place or after a collection change notification. In those cases, the method will fail to find an existing ID. The method has been updated to address these cases in previous patch. Here I have implemented a unit test to verify the case. Currently, the method is not being used.
Differential Revision: https://phabricator.services.mozilla.com/D9380
--HG--
extra : moz-landing-system : lando
Although this two receivers are guarded by checks for if they were initialized
(and so registered) there are reports of crashes because of trying to unregister
them without them actually being registered.
The underlying issue will be investigated further in bug 1505685 but for the
moment wrapping the unregister operations in a try-catch saves the users from
a crash and because the unregister is done when the app is closed
(for the MmaDelegate receiver) or when the app finished playing media
(for the GeckoMediaControlAgent receiver) the user doesn't loose any
functionality going forward.
Differential Revision: https://phabricator.services.mozilla.com/D11177
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
With this change we no longer have to handle the offset == 0 case everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D11018
--HG--
extra : moz-landing-system : lando
