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
These tests currently use legacy extensions that won't work in 57,
switch them to webextensions.
MozReview-Commit-ID: 8lZrqjYSrar
--HG--
extra : rebase_source : bf8f6db2daedcddb8c554325498da7cec5159118
extra : source : 75fe2d21cdff9767c9a96682375d261475c284d1
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
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
For both quit() and restart() methods the profile should not be reset,
unless it has been requested. The current behavior breaks various tests
which make use of quit() and session_start() and which assume that
previously set preferences are still set, eg. sessionrestore tests.
MozReview-Commit-ID: 4BxSSJPrTYF
--HG--
extra : rebase_source : 534c0608caf31c1e2cc256ad3fa8ae1972204603
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
Occasionally marionette tries to get the accessibility element while the
elements are still being built. This causes getAccessibleFor to return
null when there actually should be an accessibility element available.
Instead, if the document is busy, wait until it finishes to get the
accessibility element.
The InvalidCookieDomainError type is missing a status lookup key in
testing/marionette/error.js. This adds "invalid cookie domain" as a
reverse lookup for the type.
MozReview-Commit-ID: 69hkk28axtt
--HG--
extra : rebase_source : 19628df79d89f7fbaf821cc1847e1be241ff56af
This is needed before we can upgrade to flake8 3.3.0, as that version starts flagging these errors.
These files were modified by running:
autopep8 --select E305 --in-place -r <dir>
on the affected directories. I did it one dir at a time and verified the result after each.
MozReview-Commit-ID: FmlsfiKIbtr
--HG--
extra : rebase_source : 9df32258cadff5d27a0e72113c57f782756c0b18
To help debugging intermittent failures the --repeat option can be
used, but that doesn't stop if a failure occures and instead it
continuous until the number of specified iterations have been reached.
With --run-until-failure we can allow the harness to stop running
the tests once the first failure appeared. Without the --repeat option
specified it will repeat 30 times by default.
MozReview-Commit-ID: Jlsss4PHNbj
--HG--
extra : rebase_source : 7a74284557c19056d95520f2421b63f29349cf81
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
Due to the current caching of this.tab in browser.js the assertion
for the contentBrowser would fail. As such additionally assert that
the currently selected chrome window has not been closed yet.
Also assert.window should better check the 'closed' property instead
of handling a possible TypeError.
MozReview-Commit-ID: B79czg3dsux
--HG--
extra : rebase_source : 31bf31d2151e4b461574101ce7770d38fb92bd5c
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
Phil Ringnalda
Andreas Tolfsen
Wes Kocher
Andrew Swan
Erica Wright
Nathan Froyd
Joel Maher
Carsten "Tomcat" Book
Andreas Farre
James Graham
Henrik Skupin
Andreas Tolfsen
Sebastian Hengst
Brendan Dahl
Ignaz Forster
Andrew Halberstadt
Ryan VanderMeulen