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
I followed the guide at:
https://wiki.mozilla.org/Mobile/Fennec/Android/Task_Cluster_notes
To identify what to change.
MozReview-Commit-ID: HnKSSqym0aA
--HG--
rename : testing/mozharness/configs/builds/releng_sub_android_configs/64_api_15_frontend.py => testing/mozharness/configs/builds/releng_sub_android_configs/64_test.py
rename : testing/taskcluster/tasks/builds/android_api_15_frontend.yml => testing/taskcluster/tasks/builds/android_test.yml
extra : rebase_source : a4080ecc8afab781cbd81de7b2d2c1f9b3968757
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
The code for ensure_repo_and_revision() has been completely overhauled.
We now require shared repos using auto pooled storage via the share
extension. This ensures that only a single copy of a logical
repository's history is stored on disk. e.g. if you clone
mozilla-central, inbound, and try, they'll all automatically share the
same storage.
The new code ensures the destination repo is using modern conventions
and will delete the destination repo if it isn't. So once this gets
deployed to production, machines will slowly start using optimal
storage. This should make VCS operations significantly faster.
Another optimization that is now in here is we check for presence of the
wanted revision before doing `hg pull`. This saves some communication
with the server if the revision is already present locally.
This change effectively requires a modern version of Mercurial to be
installed to run ensure_repo_and_revision(). Since Mercurial <3.7.3 has
security vulnerabilities, we shouldn't be running <3.7.3 in automation.
So I think this will be OK. If not, it will certainly be easy to
identify which machines aren't updated!
MozReview-Commit-ID: 62jtAsDj7rU
--HG--
extra : rebase_source : a43d7f54b16e71940e45ddf05402449575fccfee
MercurialVCS doesn't currently implement the VCSMixin interface.
This commit copies the implementation of query_pushinfo() from
HgtoolVCS to MercurialVCS so it implements the interface.
MozReview-Commit-ID: LKpLVhQoKww
--HG--
extra : rebase_source : 358d37e29f9239c0b1c084c0251af7a94c1f526a
We currently have a "clone_by_revision" property that indicates to
perform a `hg clone -r`. We use it for cloning from Try.
Cloning single revisions undermines the benefits of clone bundles. So,
I'll be replacing "clone_by_revision" with a feature that clones from
another "upstream" repo then does a `hg pull -r` on the wanted revision.
This commit starts that work by introducing a "clone_upstream_url"
property. We define it on Try. It is currently unused.
MozReview-Commit-ID: Dohs8bCTUkB
--HG--
extra : rebase_source : 17b643f32747d494db04a2e80c4f94308b13618e
We no longer use <3.7 in automation. So drop support for <3.2. While I
was here, I also added magic variables to the extension so Mercurial
can react intelligently to version compatibility issues.
MozReview-Commit-ID: 4tAvQljasDR
--HG--
extra : rebase_source : ef2b5070014507533b5c0ec17449d62ba1bedad8
extra : source : 43c18590fcc7bbf7573647c2f225f4a82dd55730
The build/tools repo has a "purgelong" extension that is used to delete
long filenames on Windows. Without this extension, the APIs Mercurial
uses may run into path length issues and `hg purge` will fail.
This commit is a straight import of the purgelong extension
from https://hg.mozilla.org/build/tools minus the shebang line, which
isn't needed.
MozReview-Commit-ID: FIrEeWDf2Dl
--HG--
extra : rebase_source : ce34dc3dbcfbb9463022f3019f167a58cb396ef3
We had a test environment running on Python 2.6 and an ancient version
of Mercurial. AFAICT we run Python 2.7 everywhere, so this environment
can be dropped.
We also upgrade to Mercurial 3.7.3, as that is what automation now runs.
MozReview-Commit-ID: 7WTyD3CUjtj
--HG--
extra : rebase_source : 8e37b215fb2bff2f12658fd5ad3b61d631ec26c7
This will enable log parsers to find step boundaries easier.
MozReview-Commit-ID: G4OaViDd9Fv
--HG--
extra : rebase_source : a7e94e4ec088c4fed7eb2b7a1662e308296e8bb2
This changes to match the spec, which also aligns the behavior of get
and set (get already maps out-of-range values to the default value).
There is currently no interoperable behavior here, but this aligns us
with IE -- tested in 11, hopefully true for Edge too.
On the way, I also fixed the fact that video's height and width were
being treated as signed.
Our testsuites normally disable timeouts when --debugger or similar
options are specified. Robocop doesn't do this, because apparently the
best way to debug Robocop tests is to |mach robocop [TEST-NAMES...]|,
wait for the browser window to show, and then connect a debugger. This
setup seems suboptimal.
The setup being what it is, though, implies that runrobocop.py has no
knowledge of a debugger being connected, and therefore no idea that the
test really shouldn't time out. Which then leads to the test going away
at that crucial moment when you are this > < close to figuring out the
bug. Let's make runrobocop.py understand that --timeout means something
useful for such a context.
This function is roughly copied from browser/base/content/test/general/head.js.
It has been widely used in browser chrome mochitests, and should be fine to
have it available to all mochitests via SimpleTest.
MozReview-Commit-ID: DhIfgJiUhXK
--HG--
extra : rebase_source : 95ab1cd6c1ab5f6c0d8f0171865722ca76b41c6e
* forces per checkin clobber only on 'release' platforms
MozReview-Commit-ID: E7ZxdiYH47d
--HG--
extra : rebase_source : 1dc896d61f7392b4fb253f08de7b743c86f0eebc
extra : amend_source : 677fda6773448183580701718114642b405668bf
This adds tests for issues brought up in bug 231393, bug 264610, bug 302575 and bug 1129564,
all of which fed into the current implementation of userTypedClear/userTypedValue. I intend
to move us away from userTypedClear, but I'm keen not to regress any of these issues, so
I'm adding automated tests to ensure that doesn't happen.
MozReview-Commit-ID: 1up2MIXzkzG
--HG--
extra : rebase_source : 4d37f13895b8c7e7aba5331664718582c6b2136c
* Add new tests for single-valued keyframe to gKeyframeSequenceTests.
* Update constructor.html.ini and setFrames.html.ini so that we can use the new tests.
* Iterate all the possible tests for keyframes in animate.html (and modify .html.ini).
* Use `null` for some keyframes because assert_class_string doesn't care about details.
* Remove unnecessary call `done();`.
MozReview-Commit-ID: 6209DO9BYFP
--HG--
extra : rebase_source : 09ad64982940fba300d0884045bd22a71a0bd60a
Boris Zbarsky
Brian Birtles
Henrik Skupin
Ryan VanderMeulen
Steve Fink
Andreas Tolfsen
Michael Comella
Carsten "Tomcat" Book
L. David Baron
Aryeh Gregor
James Graham
Wes Kocher
David Burns
J. Ryan Stinnett
Joel Maher
Jan Henning
Edgar Chen
Rail Aliiev
Ben Kelly
William Lachance
Armen Zambrano Gasparnian
Gregory Szorc
Jocelyn Liu
Ben Tian
Kim Moir
Sebastian Hengst
Mihai Tabara
Nathan Froyd
Stone Shih
Bevis Tseng
Xidorn Quan
Nick Thomas
Aki Sasaki
Jordan Lund
Neil Deakin
Kalpesh Krishna
Michael Kohler
Jeff Walden
Maja Frydrychowicz
Jason Orendorff
Chris Cooper
Kim Brown
Thomas Nguyen
Jonathan Watt
Robert Helmer
James Willcox
Emilio Cobos Álvarez
Sebastian Kaspari
Gijs Kruitbosch
Lee Salzman
Andrea Marchesini
Ryo Kato
Geoff Brown
Christoph Kerschbaumer
Jessica Jong
Boris Chiou