We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 599b3b661c7a8a5db1f32a2a9732fc202fb55e1e
Add a cross-compilation copy of rust's standard library targeting
i686-pc-windows-msvc to the win64-rust toolchain package so it
can be used to build for win32 as well.
MozReview-Commit-ID: 3598VZrDjIH
--HG--
extra : rebase_source : f1b25a68a67ae7f9c505a42d17f29dbedf59a49d
- Add node as a dependency on Linux and Mac
- Add python3 for Mac only (linux generally has it installed already).
MozReview-Commit-ID: EpNWFTI9UXc
--HG--
extra : rebase_source : 755e8575e6e6c261c1ccaf9e5fe08e66502a4c3c
The clean-up code in FennecInstance now counts and logs consecutive DMErrors.
The Marionette clean-up code then throws an UnresponsiveInstanceException
if we hit consecutive errors more than twice, which interrupts the
test run entirely. (Previously, MarionetteTestRunner would just keep running
tests despite consecutive clean-up failures, and eventually it would time out.)
This change allows us to take advantage of the retry mechanism in the
mozharness script that runs all Android tests: it sets the job status to "retry"
if it finds DMError in the test log after the run_tests step is done.
MozReview-Commit-ID: J36XuFVK1aK
--HG--
extra : rebase_source : 4feada21d7b4260e73054339fa79c61911d259ee
The test was refactored in Bug 1408932, but it wasn't actually enabled.
MozReview-Commit-ID: 85vI9iX5p2V
--HG--
extra : rebase_source : 03182ab24bd057ad0be9d2e3f3e884c346d53d98
The problem with this bug was that it did not correspond to animations that
have multiple keyframes with the same offset.
In summary graph, although we were changing the resolution for the graph
creation by the distance of offset between keyframes, as the calculation of
resolution between keyframes with equivalent offset was infinite, generation
was not completed and it was in a state of freezing.
In here, in case of zero distance of offsets, we make avoiding to affect to
changing the resolution.
In addition, the detail graph did not display correctly.
For example, there is an animation below.
div.animate(
[
{
offset: 0,
opacity: 1,
},
{
offset: 0.5,
opacity: 0.5,
},
{
offset: 0.5,
opacity: 0.1,
},
{
offset: 1,
opacity: 1,
},
],
1000
);
In this animation, opacity changes from 1 to 0.5 during 0 - 499ms, from 0.1 to 1
after 500ms.
So, opacity at offset 0.5 behaves 0.5 during 0 - 499ms, 0.1 after 500ms.
Since current animation inspector creates the graph with computed value of the
time of offset, the opacity of offset 0.5 always is 0.1 in the example,
was not correct.
As a solution, same to the actual animation work, create the graph between each
keyframes with range that from start keyframe offset time to just before the
time of end keyframe offset time.
Also, in same offsets, connects between just before the time of the offset time
and the offset time.
So, in the example, we separate as below, then calculate the each coordinates,
then combine as graph shape.
1: 0 ~ 499.999ms
2: 499.999 ~ 500ms (same offsets)
3: 500 ~ 999.999ms
4: 1000ms
MozReview-Commit-ID: p4Cn2N9iFt
--HG--
extra : rebase_source : 0f175fa0b7a3c882171e59a6e4a94bb4802e96d2
Early during startup there might not be a selected tab yet, so we can't use its
data to decide which home panel to show again.
Fortunately showHomePager can be called with a null panelId, in which case it
will eventually simply fall back to using the default home panel from our
settings.
MozReview-Commit-ID: GbmozJeYZVb
--HG--
extra : rebase_source : 0ed294b6820faa1934105c2719460dd7bef1a852
The background is enabled when using a theme to increase readability of the URL,
but disabled in private mode, because we don't show the theme while in private
mode.
However for the latter feature to work, the respective layout needs to be told
about the private mode state of the toolbar in the first place. We did this
for the ToolbarDisplayLayout, but had forgotten the ToolbarEditLayout.
MozReview-Commit-ID: 3GAesHvwDEX
--HG--
extra : rebase_source : 753be3bcbdbe7fef05fddfcb77e7b69926e6fbef
<!-- Please describe your changes on the following line: -->
Sub-PR for #19015.
---
<!-- 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#19656 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because refactoring
<!-- 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: 7a9f99eda881d500ea344382d02037bfd11789da
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7543846743c59ec1d0c917efb915155e2f7e17da
Instead of duplicating Dockerfiles between taskcluster/docker/*
directories, which can be error prone for very close images, it can be
desirable to use the same file. This change allows to set the
`definition` keyword on a docker image definition in kind.yml that
will make the task use the files from taskcluster/docker/<definition>
instead of taskcluster/docker/<image_name>.
--HG--
extra : rebase_source : 11ae231f66ca6a77896c1cff6c1580d04210f052
Ideally, we'd simply use the --build-arg docker argument along with ARG
in the Dockerfile, but that's only supported from Docker API 1.21, and
we're stuck on 1.18 for the moment.
So we add another hack to how we handle the Dockerfile, by adding a
commented syntax that allows to declare arguments to the Dockerfile.
The arguments can be defined in the docker images kind.yml file through
the `args` keyword. Under the hood, they are passed down to the docker
image task through the environment. The mach taskcluster-build-image
command then uses the corresponding values from the environment to
generate a "preprocessed" Dockerfile for its context.
--HG--
extra : rebase_source : 26a43dd680c1ab97b1a4689a23c55594a3b21b67
PinForSeek() is called only when playback reaches the end. In other words,
it is not called for most cases of seeking. It should be OK not to call it at
all during seeking.
MozReview-Commit-ID: 1xXX1321bO7
--HG--
extra : rebase_source : df8ba3f59da2a337b456546af4b54abaddfe38a9
extra : intermediate-source : 0a70419f9ce639ac0784a0632db4598d6be511f8
extra : source : bfddad9b922386c91fcfa7657a7ac274991d15f4
Some methods in CSSEditUtils are unused now, so let's remove it.
MozReview-Commit-ID: H4HiqL6hW9K
--HG--
extra : rebase_source : 80e10ba5e6de5fcc5032dc2e08fa84bf26e80795
v.ended is set to true before the 'ended' event is fired. Then we can simplify
the code by asserting seekToNextFrame() should never be rejected.
MozReview-Commit-ID: 5fB2QuboU0I
--HG--
extra : rebase_source : b8662773ec6bd0c9292666d1aa29a48cb860b22b
These tests can be passed now, I don't know what fixed them, presumably
bug 1421476 and bug 1379515 fixed it.
MozReview-Commit-ID: 2srFKTWWvK
--HG--
extra : rebase_source : 418d366ade78d5a9994cb9bbbab39c4c0b42a2a4
Replace `loader.lazyGetter` pattern with normal variable assignment
MozReview-Commit-ID: I08f8hnQ0nN
--HG--
extra : rebase_source : 18d9108d1b49aad92f0c9a2223c2fff58e1dddb1
The test differs a bit from the old one since we are now testing that there is
a button to jump to definition.
MozReview-Commit-ID: DnC5uJ3pAea
--HG--
rename : devtools/client/webconsole/new-console-output/test/mochitest/test-bug_1050691_click_function_to_source.html => devtools/client/webconsole/new-console-output/test/mochitest/test-click-function-to-source.html
rename : devtools/client/webconsole/new-console-output/test/mochitest/test-bug_1050691_click_function_to_source.js => devtools/client/webconsole/new-console-output/test/mochitest/test-click-function-to-source.js
extra : rebase_source : e0700658c4a88b0e16ebf8e14102dacd52aec71f
Landings of e.g. bug 1427336 triggered new toolchain jobs. One of those
jobs, because of wrong changes in bug 1421100, downloaded a new rust
compiler beta instead of the intended fixed beta version. In turn, that
new rust compiler beta fails to compile the slog crate.
Now, because of how toolchain cache indexes work, every new win32 job
picks that new unintended rust compiler beta version, even on branches
where 1427336 hasn't landed.
I couldn't find a way to force the right beta version, so we're pretty
much stuck with that toolchain index pointing to the wrong version of
rust beta.
By backing out bug 1426324, we return to a toolchain index that is known
to have an artifact for the right rust compiler beta.
Unfortunately, if something triggers a new TW32(rust) job after this,
that toolchain index will be busted as well.
Formats the following files:
* components/layout/display_list_builder.rs
* components/layout/webrender_helpers.rs
Remove outdated options from rustfmt.toml.
Configure rustfmt to place binary operators
at the end of line (to match ./mach test-tidy).
Rationale: I am tired of indenting my patches by hand trying my best to do it correctly and match the surrounding code. Just to be told that either my indentation is wrong or that I should switch to block indentation for this function because it looks better.
The new formatting passes `./mach test-tidy`. Compared to the old formatting it is a lot more consistent but also tends to spread the code across more lines. The diff is this big because a lot of code used visual indentation.
See also #8553
Source-Repo: https://github.com/servo/servo
Source-Revision: 3692f13dcbba64741e2f8d15fc1e225667437ef6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 03e42b8bf9b41ecf90a607bcfe8b3b5647fca017