Add try command to mach & try build partitioned
Adds `./mach try` command that enables anybody to easily test their changes without opening PR and requesting try from bors-servo, by force pushing HEAD to appropriate branch. Command accepts branches names to select only partial runs of CI (same like bors try command). So if you only want to test mac build (that would be `@bors-servo try=mac`) you run `./mach try mac`. If no job is specified, try branch is used.
As partitioned CI jobs were not working after migration to GitHub Actions I remade them by using if guards.
Also WPT jobs were failing due to empty `INTERMITTENT_TRACKER_DASHBOARD_SECRET` on my fork, so I added additional check to prevent failed run.
And that concludes my work on #29379🎉
---
<!-- 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#29379
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it's CI
<!-- 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. -->
script: fix BorrowError in (new Blob).slice(0,0).text()
When getting the text of a sliced Blob, we call GlobalScope.get_blob_url_id, which borrows the blob_state field mutably and calls the get_blob_size method (aka [Blob#size](https://w3c.github.io/FileAPI/#dfn-size)), which tries to borrow the same field immutably, causing a panic.
This patch inlines the relevant parts of get_blob_size into get_blob_url_id, so we can reuse the mutable borrow.
* /FileAPI/Blob-methods-from-detached-frame.html was 4/4 FAIL, will be 4/4 PASS once #29396 also lands
* /fetch/api/basic/scheme-blob.sub.any.html was CRASH, now 10/17 PASS and 7/17 FAIL
* /fetch/api/basic/scheme-blob.sub.any.worker.html was CRASH, now 10/17 PASS and 7/17 FAIL
---
<!-- 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#29450
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
Implement URLSearchParams's size
<!-- 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#29425
<!-- 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. -->
This change updates results that are reliably flaky on the bots and also
adds bug references for previously updated results. The bug annotations
here are the same that are used for Gecko.
There are two kinds of flaky/intermittent tests in Servo. The
traditional kind is the test that fails on the CI, but has an associated
bug indicating that the test is an intermittent failure. Many of these
tests have completely unstable results, for instance those where an
unpredictable set of subtests fail. It's impossible to generate stable
results for these, so we have traditionally simply discard these
unexpected results.
Another kind of intermittent test is one that will produce an expected
result when rerun (ie will flake). Some of these are also labeled with
bugs, while some are not. In some cases, there is flakiness in some core
Servo functionality that can lead to *any* test flaking, such as a race
condition that can lead to an early screenshot for reftests. When these
kinds of tests do not have associated bugs, they cause the CI to fail.
In this case, it is impossible to label these tests as intermittent
because it can literally be any test.
This change, reruns failed tests in order to detect unlabeled tests in
the second category. Instead of blocking the CI when the second run
leads to expected results, the CI will now pass, but the flake will be
reported to the new flakiness dashboard. This prevents unrelated flakes
from slowing down the merge queue.
These tests test the behavior of many properties and due to issues in
Servo, the results are incredibly unstable. Since the tests use large
property lists this leads to hundreds of failed subtests every run. We
let these tests either pass or fail so that results in the CI are
stable. The ultimate goal here is to fix the instability in Servo so
that these tests pass or fail consistently.
This change also adds support for intermittent expectations to the
ServoHandler. Before these kind of test results were interpreted as
unexpected results.
Add support for the intermittent dashboard
<!-- 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 do not require tests because this is a CI change.
<!-- 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. -->
Use the new intermittent dashboard to report intermittents and get
information about open bugs. This is now used to filter out
known-intermittents from results. In addition, this also allows the
scripts to report bug information to the GitHub. Display that in all
output.
Add a "shmem" feature to selectors to avoid publishing that dependency
<!-- Please describe your changes on the following line: -->
Hopefully as a way to help #29105, this PR adds a `shmem` feature to the selectors crate. This is so that the crate can be released with that feature off by default, as the `ToShmem` derives are only of interest to Servo, I think.
All the places where servo's source code includes the selectors crate are made to turn on this feature.
Aggregate unexpected results into logs
This makes it easier to run `update-wpt` based on results from the bots by writing a new version of the raw log that filters out all tests with expected results. Then aggregate this output into the filtered results archive. A future version of this could aggregate all unexpected results that were not filtered as intermittents.
<!-- 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 do not require tests because they are infrastructure changes.
<!-- 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. -->
This makes it easier to run `update-wpt` based on results from the bots.
A future version of this could aggregate all unexpected results that
were not filtered as intermittents.
Fixes the test case `/_mozilla/css/css-transition-cancel-event
.html`, which was failing under a specific circumstance.
The observed sequence of events during the failing test run looks like
this:
1. Transitions start in `div1` and `div2`.
2. `div1` generates a `transitionend` event.
3. The `transitionend` event handler removes `div2` from DOM, cancelling
its ongoing transition.
4. `div2` is supposed to generate a `transitioncancel` event in a timely
manner, which it does not. The test fails as a result.
What is going on here? Here's a possible explaination:
1. During one invocation of `ScriptThread::handle_msgs`...
2. In step 2, `ScriptThread::update_animations_send_events` -> `Document
::update_for_new_timeline_value` detects the completion of the
transition, and in response, pends the `transitionend` event.
3. In step 3, `ScriptThread::update_animations_send_events` ->
`Animations::send_pending_events` calls the `transitionend` handler.
4. The `transitionend` event handler removes `div2`, thereby cancelling
its ongoing transition and triggering a reflow.
5. Reflow takes place. During this, `Animations::do_post_reflow_update`
-> `Animations::handle_canceled_animations` pends the
`transitioncancel` event (precursor to step 4).
6. Having discovering that there was no running animation, `Animations::
do_post_reflow_update` calls `self.update_running_animation_presence
(_, false)`, which sends `AnimationState::NoAnimationsPresent`.
7. The invocation of `ScriptThread::handle_msgs` ends, and another
starts. It blocks waiting for events.
8. Meanwhile, the compositor receives `AnimationState::
NoAnimationsPresent` and stops further generation of animation ticks.
9. With no events to wake it up, the script thread is stuck waiting
despite having the pending `transitioncancel` event (step 4).
The HTML specification [says][1] that "an event loop must continually
run [...] as long as it exists" and does not say it can block if there
is nothing to do. Blocking is merely optimization in a user agent
implementation. Pending animation-related events must be processed every
time a "rendering opportunity" arises unless the user agent has a reason
to believe that it "would have no visible effect".
Skipping the processing of animation-related events would have visible
effect if such events are indeed present. The correct implementation in
Servo, therefore, would be to request more animation ticks so that such
events are processed in a subsequent tick.
[1]: https://html.spec.whatwg.org/multipage/#event-loop-processing-model
Bump euclid to 0.22
Major changes:
- All matrices are now stored in row major order. This means that parameters to rotation functions should no longer be negated.
- `post_...()` functions are now named `then()`. `pre_transform()` is removed, so `then()` is used and the order of operations changed.
In addition, this PR updates lyon_geom to the latest version.
<!-- 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#27424
- [x] There are tests for these changes
<!-- 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. -->
