<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1329361
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 310408a82851d05db3b310ac5b9cdf49a33e1990
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : eb5ace9ef5748ac7679eac3997104e4f3a7e8f0b
The VP9 decoder doesn't properly set the sample duration, leading to all samples being marked as having a zero duration.
The compositor drops those frames incorrectly. This issue will be addressed in bug 1222874.
MozReview-Commit-ID: JQdtTL4nAN
--HG--
extra : rebase_source : 7c69cd3522c4b2231a07ab3f3c1d012843ac2f69
Using a float to store the last duration was unwise (as it has only a 24 bits mantissa), luckily it wasn't used except very particular circumstances.
MozReview-Commit-ID: BpL8ufQFNeR
--HG--
extra : rebase_source : b4a5a1301be4a0a81d1907b6296cbb4b6c4877d9
SupportsMimeType is called in the content process, for which, following bug 1338011, dxva is marked as disabled.
CanCreateWMFDecoder already performs the check of allowing VP9 only if it's hardware accelerated, so we don't need to test if dxva is enabled prior.
MozReview-Commit-ID: 7Jvaop6ZznU
--HG--
extra : rebase_source : 854e7b09718863e710843d11c9327de47abf1076
The level is a u8, so on 64-bit it packs nicely after the u32 specificity.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1371297
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: ca8961a93bd5dfb2680ed0cb73a5fcc0ce0f0fdb
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 50e8378984e0b24cde80ee88d52c0a58ab123cc5
Bug 1356952 defined tooltool manifest at the taskcluster job definition.
This makes many definitions from mozharness now redundant.
While this would ideally have been done in bug 1356952, some of those
definitions are likely to still be used by some buildbot job or some
obscure taskcluster job seldomly triggered. Preparing for the
possibility that this might burn some jobs, making this removal
backout-able independently allows other work to happen on top of bug
1356952 without the risk of everything having to be backed out because
of some random bustage.
--HG--
extra : rebase_source : 73fdb7747a51ddc57fe41a9493893e293cd3bbc4
Enable av1 decoding with the aom reference library on nightly
build except on Windows and Android where it's not working yet.
This codec is under development and subject to incompatible
changes. We're supporting a specific encoder revision for
testing with website authors to get early feedback.
See media/libaom/README_MOZILLA for the specific codec commit
hash our decoder expects.
MozReview-Commit-ID: JCPiVFg3geC
--HG--
extra : rebase_source : c7b9de67415d885ada64658f8f938b4091b468e3
<!-- Please describe your changes on the following line: -->
Defines and calls Gecko CounterStyle and FontFaceRule clone functions, protected by cfg directives to only apply in gecko builds.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 0dc3fbfce3263cb8aabbed8c5f9b856a12e59460
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6cb70fdf71faf596bed18e11c9a1051fa49007ce
Make sure we test the other major container we
need to parse correctly.
MozReview-Commit-ID: AnrGADFXPkw
--HG--
extra : rebase_source : 5e20580d0900a62f923b96089410845c187ac2a7
The approach here is similar to the FasterMake backend, but rather than writing
out manifest entries to a backend file to be written out during the build
we write the manifests to their final location within the build backend.
MozReview-Commit-ID: L7EPwxyFtWX
--HG--
extra : rebase_source : ee40f43a61560584ab03b63eae0f5c03d2c5c0e0
Prefer the vs14 targets since we build for Windows
with cl instead of cygwin's gcc. This corresponds
to Visual Studio 2015.
In practice there is little difference, other the
upstream build system assuming a Visual Studio style
output directory, but this should help pick up any
compiler-specific work-arounds.
MozReview-Commit-ID: 4etKKIEJWws
--HG--
extra : rebase_source : 5d03abdda718ed7811dc5d22cc56586d84d207d9
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1369621
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 612f2c1c2a9e56de2abe9ce32fcb6461a133686d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 89a0524ef12c025009488f127ecc083a71ba646b
We updated win64 builders to rust 1.18 while it was still in
beta to pick up better crash reporting. Bump those builds to
the stable toolchain now that it's released.
MozReview-Commit-ID: 1LlmrDfLfWL
--HG--
extra : rebase_source : 4c14198cf962db26a072cd4b6316edbe870cf5bd
This is no longer necessary with the 1.18.0 release.
MozReview-Commit-ID: 1IGQFuvRIzu
--HG--
extra : rebase_source : 4eb4daea4edfed48db388814240f9241021a2029
This version offers a 15-20% improvement to compilation
speed, so we will likely require it for developers soon.
Begin installing it now to reduce the frequence of double
migrations.
MozReview-Commit-ID: JZRssgOjkF7
--HG--
extra : rebase_source : 7d2ef10315c570e21d609f713391be3e82a88383
This ensures that developers can run the majority of tests with the
default config, but makes things a little more confusing for marionette
developers.
MozReview-Commit-ID: 9wd761ZgCyx
--HG--
extra : rebase_source : d601fa10d1896afd3c450b2d44a2024b9963096f
This is just the servo part change. The test part will be landed in gecko directly.
Gecko bug: [Bug 1369624](https://bugzilla.mozilla.org/show_bug.cgi?id=1369624)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0dc7190311edf3d30605615546677258ea0aab7e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f386791d09e2947bfa193fbe5e85be07e6c5ac90
When a call through the content frame proxy is interrupted by the
dialogueObserver, the synchronous promise that is meant to wait for a
response from the frame script is resolved immediately with an undefined
return value.
When an undefined value is assigned to the response body, it gets dropped
during JSON serialisation. To ensure the "value" field expected from
the Execute Script and Execute Async Script commands is populated,
we need to assign a null value to resp.body.value.
We can treat undefined as null by calling evaluate.toJSON again on the
return value from the proxied frame script call. This effectively means
we serialise it twice, since it first needs to be serialised to cross
the IPC border, though the second computation only looks at primitives
and no known web element store is required.
It would be nicer if the content frame script itself would be able to
return early with null by installing a user prompt notification event,
but this is not possible because the tabmodal dialogue that appears
blocks script execution. This means we need to rely on the
dialogueObserver in testing/marionette/proxy.js to take care of the
dialogue for us.
MozReview-Commit-ID: D14TA2TYYXI
--HG--
extra : rebase_source : 5fc17a1f0786e2fc9a2d054ef7c1f8b0e3336906
Removes the Marionette.import_script API as it is not used by any
consumers of the client, including the Firefox UI tests.
MozReview-Commit-ID: 3xceYXZZVR0
--HG--
extra : rebase_source : 7422704737da599704125874a6f52e4eeb670dfd
The import script functionality was removed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368648, but the
Marionette.clear_imported_script API was not removed from the client.
We are currently making calls after every test to the clearImportedScripts
command in the server, but we are apparently ignoring the ‘unknown
command’ error that is being returned.
MozReview-Commit-ID: KVjh2IfhuUY
--HG--
extra : rebase_source : ebc8faf8746e7e3e91b395ec488aeea014747848
This environment variable works on both Windows and Linux for force-disabling
the content sandbox, and now does so on macOS as well.
The xpcshell tests force disable the sandbox because they do things like bind()
sockets, which is not compatible with the content sandbox. This is needed now
because bug 1358223 was force upgrading the sandbox from level 0 (disabled) to
level 1 on beta channel, which caused breakage.
MozReview-Commit-ID: 5DGxtoDLp0C
--HG--
extra : rebase_source : 87edd138e8b711eace5cb8103c67feae0361e148
This involves a few changes:
- Remove the .exe from the makensis binaries. which.which will
auto-add it so Windows will keep working - and with it
present we were finding makensis.exe on Linux and trying to
run it, which isn't going to work
- Doesn't bother checking if nsis is 32bit if we're running on
Linux
- Add the -nocd option to nsis (on Linux) because it takes the
current working directory from the target of a symlink rather
than the symlink itself. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704828
MozReview-Commit-ID: CVT8LwS1t8w
--HG--
extra : rebase_source : 2a62327326ba80dfd728048d19f0ff1c90100838
Also bypasses bug 1371332 by ignoring MozAfterPaint events with empty rects.
MozReview-Commit-ID: GSBlPSrQxo9
--HG--
extra : rebase_source : 981d2f42285c843599a3ecad4225917cdcc4b536
