In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
This adds support for #rgba and #rrggbbaa colors to CSS. This feature
is specified in https://drafts.csswg.org/css-color-4/#hex-notation .
This adds new types to nsCSSValue so that we can serialize the syntax
that was specified, as we do for other distinctions in how colors are
specified.
It does not change the behavior of the hashless color quirk, which
continues to support only 3 and 6 digit colors as specified in
https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk (step 4).
This changes property_database.js to remove various uses of 4 and 8
digit colors as invalid values. It then adds them in slightly fewer
places as valid values, but more thoroughly testing both initial and
non-initial values on 'color'.
It marks two canvas tests explicitly testing this feature as no longer
known to fail by removing their .ini files.
Finally, it adjusts the web platform test testing the hashless color
quirk to no longer treat 4 and 8 digit colors with hashes as invalid
values. Removing the relevant test items seems like the right thing
since they're in a section where 3 and 6 digit colors were skipped but
other lengths were tested. Modifying this imported test is OK since:
<jgraham> dbaron: Commit the change you want to m-c, it is
(semi-)automatically upstreamed every so often (typically
about once a week)
MozReview-Commit-ID: IFq4HxaRkil
This follows a spec change <https://github.com/whatwg/html/issues/293>,
which AFAIK no other browser has implemented, so it has some regression
potential.
The web-platform tests changed are out-of-date and match the old spec,
so I'm changing them here to match the new spec.
This allows use to be able restore the window size if we wanted to.
MozReview-Commit-ID: Kx3JH1UroI2
--HG--
extra : rebase_source : 1b41e6b488eee2b4cbbea1104323b5807890b368
During tests that open additional tabs, the main test tab controlling the test is at risk of being zombified if a memory pressure event arrives, which breaks the test and leads to the test timing out. Therefore, we now disable background tab zombifications during tests.
This means that there's a slightly increased risk of being OOM killed instead, however
- the tabs opened by the tests themselves are normally relatively short-lived anyway
- we're no worse off than if the tab containing the test harness code had been zombified.
MozReview-Commit-ID: 1Ntvn4yjWlZ
--HG--
extra : transplant_source : %E78%93%3B%0F%5DnX%BC%E6G%10%B2%B5%1B%3A%9F%CE%F9%DD
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
--HG--
extra : rebase_source : 38cc7b1e374fd42afb213133fd1a5e11bf8bdd95
This removes a hack that was left behind so to not break eideticker
and mochitests on b2g.
MozReview-Commit-ID: 3n02qaAIPyp
--HG--
extra : rebase_source : 5e81c5ee42e152681f7306185c49f4b4628ac9b6
hgtool printed the hg version info when running. This is useful data
when debugging Mercurial failures. Add it back in.
We also add `hg debuginstall`, which prints useful bits about the
install, including the Python path and version.
MozReview-Commit-ID: IeKhfWDXEys
--HG--
extra : rebase_source : 93496db608a2f9480e521c526e30a25646583997
Now that the MercurialVCS VCS tool does things optimally, we no longer
need to use hgtool!
Again, this will effectively require a modern Mercurial version or
things will fail.
MozReview-Commit-ID: 9SM9qfYGlU6
--HG--
extra : rebase_source : 541303fb53a4ebd9aa4fd3313f8c72182d01ad37
Brian Birtles
Henrik Skupin
Ryan VanderMeulen
Steve Fink
Andreas Tolfsen
Carsten "Tomcat" Book
James Graham
L. David Baron
Aryeh Gregor
Wes Kocher
David Burns
J. Ryan Stinnett
Joel Maher
Jan Henning
Edgar Chen
Rail Aliiev
Ben Kelly
William Lachance
Armen Zambrano Gasparnian
Gregory Szorc