I'm removing this no-longer-used feature because it promotes a behavior
(using the default 0 minimum) that means we never see reports of
unexpected passes when the bugs are fixed, and thus aren't protected
from the bugs regressing again.
Differential Revision: https://phabricator.services.mozilla.com/D3566
--HG--
extra : moz-landing-system : lando
This patch adopts Logger#managerLevelFromPref from Log.jsm to set
and keep track of the Marionette logger's verbosity.
This has the advantage that we do not have to roll separate
implementations of Log for the child- and parent processes. It also
has the upside that the log level will be reflected when changed
at runtime through the use of an observer.
Summary: No longer used since it stopped being built as an extension.
Reviewers: dbaron
Reviewed By: dbaron
Bug #: 1467541
Differential Revision: https://phabricator.services.mozilla.com/D2663
--HG--
extra : histedit_source : a75301c90c962ce870b3c28dd0a79339ba81aa5d
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
We need to call ReadTests because otherwise we wouldn't recompute `g.urls`.
Similarly, we don't want to throw when there are no remaining reftests, since we
handle that case properly.
Differential Revision: https://phabricator.services.mozilla.com/D2069
--HG--
extra : moz-landing-system : lando
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Reftest manifest parsing fails to recognize individual tests with ? in the name. We missed this as in aou
Tes Plan:
Differential Revision: https://phabricator.services.mozilla.com/D1667
This moves reftest-preferences.js to:
testing/profiles/reftest/user.js
Developers can also now add extensions to:
testing/profiles/reftest/extensions
MozReview-Commit-ID: IVLsT5MWtcJ
--HG--
rename : layout/tools/reftest/reftest-preferences.js => testing/profiles/reftest/user.js
extra : rebase_source : 1725627d439998d92545e0d4693fbb76a266945f
These tests rely on an optimization within Gecko where it stops firing
MozAfterPaint events if there was no visible change to the generated
layers. This allows the reftest harness to exit the
waiting-for-MozAfterPaint loop and proceed with the test. However, with
webrender, this optimization does not exist and so the loop never exits.
In order to solve this problem, this patch adds an explicit mechanism to
exit the loop by means of a class attribute on the root element of the
test page.
MozReview-Commit-ID: 17ta5kLPDr9
--HG--
extra : rebase_source : 96ea462274724c6c65f1186f473bc1767253fd6b
Instead of downloading the build artifacts (rather hackily) in moztest.fixtures, this now happens
directly in the taskgraph module via the run-task script.
For now extraction and setup happens in the task's command key. It might be a good idea to figure
out a syntax to tell run-task to do this extraction, e.g something like:
run:
using-artifacts:
build:
target.tar.bz2:
extract: true
path: /home/worker/build
name: firefox
But for now I wanted to avoid this extra complexity, so maybe it could be done in a follow-up.
MozReview-Commit-ID: KOhFFpFdP7Y
--HG--
extra : rebase_source : dcea36661fa9c6442c76c850ccc67f8f6d924fda
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 45f0f8f11698890fae0dcca71174f88dbdb412c8
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 11a5264758ab3b2d8faef1e50a666981988457f2
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
For the promise as returned by "OS.File.read()" the catch handler
is missing, and as such the tests will never be started when
the call to "read()" triggers an exception. It also results in
a hang of the reftest harness.
To prevent this, the failure has to be handled and appropriately
reported.
MozReview-Commit-ID: IX9thgjjahS
--HG--
extra : rebase_source : 963cd0aeb593b7627603566d1ad08d5e0863142f
Switching from {get|set}CharPref to {get|set}StringPref allows
the reftest extension to also support preferences with Unicode
strings.
MozReview-Commit-ID: FUBjhmr0VIS
--HG--
extra : rebase_source : 53e1a020f8e2875c35ce1dfc06aff41ea18ce127
This happens when an nsIFrame* that builds an nsDisplayWrapList is deleted, but then the memory is immediately reused for another frame that builds the same type display item, within the same display list.
PreProcessDisplayLists chooses not to descend into the nsDisplayWrapList for the deleted frame, and so mOldItems remains uninitialized for the old sublist.
When adding the new instance, IsChanged returns false, since the pointers are the same, and we're checking HasDeletedFrame on the new instance (where it's never true), instead of the old. We then recurse into MergeDisplayLists, with an uninitialized mOldItems array, and crash.
I haven't added a test because I haven't yet figured out how to create a minimal testcase, and the test would rely on implementation details of the frame allocator to remain unchanged to be useful.
MozReview-Commit-ID: pHimEvfAND
--HG--
extra : rebase_source : 10baa8cabf1eca8d592f2be0eb7bc7c9461f9785
In the state of STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, we flush all pending
styles and layout and wait for a MozAfterPaint that caused by the flush. This
will be repeated until neither pending styles nor layout exists. But if there
is any throttled animation, flush for the throttled animation might
cause a new MozAfterPaint. That means that we will get stuck until the
throttled animation finished.
In this patch, to avoid this situation, we don't flush throttled animations in
the state of STATE_WAITING_TO_FIRE_INVALIDATE_EVENT.
MozReview-Commit-ID: LUz279w3Yoj
--HG--
extra : rebase_source : 9a1f0fa791645d46c3105c1ba56a2cf5914ffa9d
You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
Once we reached the state of STATE_WAITING_TO_FINISH, we just need to wait for
the final MozAfterPaint which is corresponding to flushRendering() after
"reftest-wait" removal.
MozReview-Commit-ID: EJxDYUnqbmr
--HG--
extra : rebase_source : fdb5c30142def4c0138bc6af2c510d85f30ed7f3
We no longer support legacy extensions with e10s shims, and the only remaining
uses that matter are in-tree test harnesses, which have been fixed. This flag
no longer serves a purpose.
MozReview-Commit-ID: EdCNqF4MttN
--HG--
extra : rebase_source : 0fef334354faa7541628614cb964a29faaa9df41
This includes simplifiying the startup process, migrating to a new
pref namespace, renaming files, and updating references to the code.
MozReview-Commit-ID: A2cYpsjCOAE
--HG--
extra : rebase_source : a47e156160e2e0f85f0000703f2da24e781c727d
This includes simplifiying the startup process, migrating to a new
pref namespace, renaming files, and updating references to the code.
MozReview-Commit-ID: A2cYpsjCOAE
--HG--
extra : rebase_source : abf1f517b78952d42b0142ca458444eed61c939a
Run-by-manifest is a mode where we restart Firefox between every manifest of
tests. It sacrifices a little bit of runtime for better test isolation and
improved stability.
This turns run-by-manifest on for all platforms except Android. It also skips
jsreftests and crashtests for now (mostly to limit the scope of what was
landing all at once). Follow-ups will be filed to get it turned on in those
places.
MozReview-Commit-ID: DmvozAIPE5Q
--HG--
extra : rebase_source : 67470894a7aa0b3189380a4874495395401909bb
The point of start-after-crash was to resume running tests after a crash so we
don't miss out on test coverage when a crash happens. Now that we're close to
landing run-by-manifest, this feature is as necessary since only tests that
appear later in the same manifest as the crashing test will be skipped.
Another reason to remove it, is that it's current implementation is buggy. It
assumes tests have a unique ID (they don't), which means we could accidentally
get into an infinite loop if the wrong test happens to crash at the wrong time.
A third reason to remove it is that it adds a lot of complexity to the harness.
Especially now with run-by-manifest, supporting both would require handling a
lot of different edge cases and make things much more complicated than the
already are.
All that being said, it would still provide value. Not only would it allow us
to resume tests in the same manifest, but run-by-manifest isn't yet enabled on
Android, jsreftest or crashtest (though we hope to get it enabled in those
places in the future). So it may be worth re-implementing start-after-crash
again based on the new manifest parsing mechanism that run-by-manifest uses. It
should be possible to implement it a lot more cleanly now. This work will have
to be left to a follow-up.
MozReview-Commit-ID: P2hh5VecKW
--HG--
extra : rebase_source : 809d5103b8d513c709aa950b102d3efee28fb205
This implements a chunk_by_manifest algorithm. It is similar to chunk_by_slice
in that it tries to make an even number of tests run in each chunk. However,
unlike chunk_by_slice it will guarantee that tests in the same manifest will
all run in the same chunk. This makes it suitable to use with run-by-manifest.
This means the chunks won't be perfect (as manifests are differnet sizes). It
is also prone to more randomization, similar to chunk-by-runtime.
In fact, this algorithm is nearly identical to the chunk-by-runtime one, so it
was refactored out to a base class.
MozReview-Commit-ID: HI2ByxW0i8V
--HG--
extra : rebase_source : e066c034b85222d26bafe6873a80366d5bd9df9e
Pass --appname org.mozilla.geckoview.test to 'mach mochitest' or
'mach reftest'. This runs the tests without e10s currently.
MozReview-Commit-ID: 7TIvA3zRCw2
Set pref datareporting.healthreport.uploadEnabled=false during mochitests
and set pref toolkit.telemetry.server to a dummy server during reftests
(uploadEnabled was already false for reftest and the telemetry server was
already set for mochitests - now these prefs are consistent).
Some mochitests failed with this change; they are updated to
set datareporting.healthreport.uploadEnabled where required.
This is part of the work to remove XUL overlays. This overlay is only
used once and can be inlined.
MozReview-Commit-ID: 1SE1nobgehE
--HG--
extra : rebase_source : 33d73fa8538da9af626feb53267278ac97554710
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
Subtly, some legitimate strings end with what, in ISO-8859-1, is
considered as whitespaces, and because the preprocessor largely works
on byte strings (str), and because the regexps are using re.U, those
characters (e.g. 0xa0) that can legitimately appear in byte strings of
UTF-8 encoding, are treated as whitespaces. So we remove the re.U from
the instruction regexp, so that only plain ascii whitespaces only are
stripped out.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : b695dec025c55aee0e50f2a0047278fe9c849c9e
This is also to improve a race condition (bug 1416125), which can happen in the
manifest parsing code on Android jsreftests. For more details, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1392391#c39
MozReview-Commit-ID: 8qLm1t8agZG
--HG--
extra : rebase_source : 260cbfef9d3bf4be959783f750ca427b34e64486
This replaces reftest's homebrewed chunking algorithm with the one that
all the other test harnesses use in manifestparser.
For now Android will continue to use the reftest based algorithm.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : ddc93e7f04e133668a98f050259559a58ff9923c
Instead of parsing the manifests and running the tests all in one go, this will
spawn an extra Firefox instance at the beginning that does nothing but parse the
manifest and dump them to a file.
This will allow the python harness to load and manipulate the test objects, before
sending them back to the JS harness as a list of tests to run. The main motivation
for this change is to implement run-by-manifest, a mode where we restart the
browser in between every test manifest. But there are other benefits as well, like
sharing the chunking logic used by other harnesses and the ability for the python
harness to stuff arbitrary metadata into the test objects.
For now, Android will continue to parse the manifests and run the tests all in one
go. Converting Android to this new mechanism will be left to a follow-up bug.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : 82e611e8795150daf01d791ea16517ec1ffb2896
Currently manifest parsing happens within the StartTests method. This method is
already quite large, and this commit series about to make the logic around
gathering tests a lot more complicated.
This commit pulls the manifest parsing out into a new 'ReadTests' method which
is responsible for retrieving the list of tests (however that may be) and then
calling StartTests.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : d494a8665d5019f73631ab8283b6d0c7759ac3bf
This is a simple refactor of manifest.jsm.
We'd like to access the test objects from the parsed manifest in python. This
will allow us implement things like runByManifest (to improve intermittent
stability), share the chunking logic used by other harnesses, and much more.
To do this, we need to JSON serialize all of the test objects and dump them
to a file. The python side can then load the file, make modifications, and
send it back to the JS side to run.
The problem is that we turn the test urls into nsIURI objects as soon as they
are parsed, which isn't JSON serializable. This commit is a simple refactor to
delay this from happening. Instead, we will create the urls in reftest.jsm,
after the modified test objects have been loaded from python. This step will
be implemented by the next commit.
MozReview-Commit-ID: 6ijOqhNaig
--HG--
extra : rebase_source : fbfa259121a8d79bfc44695397d0d1ce08123558
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <