This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
The following python-test paths are being moved out of 'make check' and into their own task:
- python/mozlint
- testing/mozbase
- tools/lint
The following python-test paths previously did not run on Windows:
- python/mozterm
- testing/marionette
- testing/raptor
- tools/tryselect
MozReview-Commit-ID: C07FANaYzf7
Depends on D10758
Differential Revision: https://phabricator.services.mozilla.com/D10759
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This adds an extra field to the reftest comaprisons to hold the
minumum/maximum allowed differences per pixel channel and the
minumum/maximum number of pixels that may differ.
Differential Revision: https://phabricator.services.mozilla.com/D9129
--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
`app.update.auto` should actually never have been needed here. `app.update.disabledForTesting`, and before that, `app.update.enabled` will prevent updates altogether. Now that the `app.update.auto` pref is not the correct mechanism for disabling automatic update, this pref should be removed from these files.
`app.update.enabled` can also be removed from prefs.rs at this time as per the comment in the file indicating that it can be removed when Firefox 62 stabilizes.
Depends on D10315
Differential Revision: https://phabricator.services.mozilla.com/D10780
--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
The singleTap and acceptConnections commands are deprecated in
favour of, respectively, Marionette:SingleTap and
Marionette:AcceptConnections.
Differential Revision: https://phabricator.services.mozilla.com/D10835
--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
As a backwards compatibility measure following bug 1388424 which
removed the ability to set the session ID, we duplicated the
capabilities dictionary in the request body.
Since this shipped through all the trees as part of Firefox 60,
we can now drop this compatibility measure.
Differential Revision: https://phabricator.services.mozilla.com/D10733
--HG--
extra : moz-landing-system : lando
The test_window_fullscreen.py test is not run because it is not
part of the test manifest. Since it is duplicated by WPT test,
we will not try to resurrect it by fixing the test.
Differential Revision: https://phabricator.services.mozilla.com/D10710
--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
Using a startup timeout of 0s should always cause an IOError,
even for builds which startup within 100ms (pgo, Nightly opt).
Further the test should not modify the internal startup timeout
property, but pass the timeout as parameter to "start_session()".
Differential Revision: https://phabricator.services.mozilla.com/D10224
--HG--
extra : moz-landing-system : lando
We often use TimedPromise to ensure Marionette does not unexpectedly
block on a promise that, for whatever reason, does not resolve.
It can however be useful to be alerted when they don't, as it quite
often means there is an underlying problem.
Depends on D8406
Differential Revision: https://phabricator.services.mozilla.com/D8407
--HG--
extra : moz-landing-system : lando
The stack is joined with "\n" causing an extra carriage return line
feed to appear at the end of the string.
Depends on D8405
Differential Revision: https://phabricator.services.mozilla.com/D8406
--HG--
extra : moz-landing-system : lando
When the in-view centre point contains a floating point, we need to
ensure to convert it to CSS pixels before passing it on to Gecko internals
such as DOMElement.elementsFromPoint and DOMWindowUtils.sendMouseEvent.
For example, with a click target that is a 1x1 square, the in-view
centre point prior to this patch was calculated to (0.5,0.5).
elementsFromPoint will (correctly?) round this coordinate down and
return the paint tree for the DOM element at (0,0) coordinates.
By contrast, sendMouseEvent will click coordinates (1,1) because it
rounds up. To make sure we all speak the same language internally,
we round the centre point down.
Differential Revision: https://phabricator.services.mozilla.com/D8880
--HG--
extra : moz-landing-system : lando
Firefox uses different shutdown timeouts for the terminator thread
depending on the build type. For opt/debug builds this will be 60s,
while for ASAN builds 180s are used.
Currently Marionette only takes the 60s into account, and always
kills the binary after 70s if a shutdown hasn't happened by that
time. This actually prevents the background hang monitor to kill
Firefox for ASAN builds, and to report a meaningful crash report
for the shutdown hang.
To inform clients about the correct shutdown timeout, a new vendor
specific capability with the name `moz:shutdownTimeout` is used as
part of the new session capabilities.
Depends on D9227
Differential Revision: https://phabricator.services.mozilla.com/D9228
--HG--
extra : moz-landing-system : lando