The PATH defined for mingw builds was cargo culted, lacks
/usr/local/bin, and contains things that are pretty much useless these
days, now that we're off buildbot. Similarly, LD_LIBRARY_PATH is
useless.
While many other similar changes could be done to the other mozharness
configurations, figuring out which ones are used under what
circumstances is more work than I'm ready to put (I started, but I
stopped when I encountered jobs that don't even run on try or central).
--HG--
extra : rebase_source : dbcbcf9ba80ebb2858c3d47a186daa367afa2988
DAMP doesn't seem to require running Firefox once before running the tests.
DAMP results are about the same with/without warming up the profile.
MozReview-Commit-ID: F9ECgRfxxWY
--HG--
extra : rebase_source : 8c1ce177b12305de3ffa5bebf0e360f880d7a5c7
The return value from Cu.import() does not include lexically scoped
symbols so stop using it here. Also stop using Extension.generate()
while we're here.
MozReview-Commit-ID: HnX3RGgDHbR
--HG--
extra : rebase_source : b4e238f2a5f1c9dce838b4dd70447edd9f401c10
Today's xpcshell harness includes a line for known failures ("Todo:"). This
change makes mozharness aware of that, which avoids test-verify failures when
the test is annotated as failing.
SynthesizeDrop synthesizes a dnd operation by starting a drag session and firing mouse events. Tweak the API to follow the order of real use cases.
MozReview-Commit-ID: 1SdJPUtSVKq
Bug 1382444 added this line to testing/profiles/prefs_general.js:
> user_pref("places.database.lastMaintenance", 7258114800);
(7258114800 seconds after 1970 is the start of the year 2200.)
libpref stores integers prefs as int32_t and the current parser doesn't detect
overflow. So this overflows to -1331819792. (I detected this with the new prefs
parser from bug 1423840, which does detect integer overflow.) As a result the
condition testing this pref in
toolkit/components/places/PlacesCategoriesStarter.js ends up always succeeding
in tests, which is the exact opposite of what was intended.
This patch changes it to 2147483647 (the year 2038), the maximum int32_t value.
MozReview-Commit-ID: LJQmMqQ9hFL
--HG--
extra : rebase_source : 84339c8e721abd47cb3cc85c3923a04417b1bbee
Some tests need to find out js/src to locate their test
data. Exporting this information as part of the environment.
MozReview-Commit-ID: JAefL2arhJL
--HG--
extra : rebase_source : b99d55c4ab4335ea938d8f3a9c733ea74f02fddf
The fact that the queues were not drained on exist seemed to cause an
intermittent failure where one process tried to write to a queue that
another had closed. Draining the queues explicitly should avoid this
and ensure we surface hidden problems in the log.
MozReview-Commit-ID: 8ulLNpIcj5z
--HG--
extra : rebase_source : 1234d368a4ef4eedd4a40835ff2d284bbe04f3f3
At least when the animation-name length is bigger than the animation properties,
we mess up inheritance and only set properly the specified counts, then don't
cycle it.
The nicer fix for this is making these vectors properly, and move the cycling
logic at used-value time (bug 1420928). Same for transitions.
MozReview-Commit-ID: 3cguzIvfMFU
According to :birtles, it is not guaranteed that animationiteration
event will be fired. This event is sample-based rather than event-based,
and such behavior has been clarified in CSS Animations Level 2:
https://drafts.csswg.org/css-animations-2/#event-dispatch
Also, Chromium has the same issue with this test:
https://bugs.chromium.org/p/chromium/issues/detail?id=701445
MozReview-Commit-ID: KBCzkGHxbfc
--HG--
extra : rebase_source : 1d9983ecf8cd9e9297bdb5e76ff26e0c7783d15e
arthur.iakab
Emilio Cobos Álvarez
Sebastian Hengst
Jon Coppeard
Florian Quèze
Mark Hammond
Mike Hommey
Cosmin Sabou
Connor Sheehan
Alexandre Poirot
Ciure Andrei
Ben Hearsum
Dorel Luca
Geoff Brown
Gurzau Raul
Vedant Chakravadhanula
Olli Pettay
Leni Kadali
Aki Sasaki
Andrew Swan
Gijs Kruitbosch
Tom Prince
Stone Shih
Nicholas Nethercote
David Teller
Tiberius Oros
James Graham
Byron Campen [:bwc]
Csoregi Natalia
Xidorn Quan