Support translation in webxr on desktop
This makes it possible to roam around webxr scenes using the WASD keys, and the arrow keys continue to change the user's orientation.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#24773
- [x] These changes do not require tests because no tests for interactive webxr content
Avoid recompiling script every time surfman changes
<!-- Please describe your changes on the following line: -->
Uses a version of webxr where webxr-api doesn't depend on surfman, so we can make changes to it without rebuilding script.
---
<!-- 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 it's just build issues
<!-- 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. -->
Fix revoke blob url
<!-- Please describe your changes on the following line: -->
fix#24290
---
<!-- 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#24290 (GitHub issue number if applicable)
<!-- 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. -->
Set response mime_type based on Content-Type
<!-- Please describe your changes on the following line: -->
Set the response's `mime_type` based on its `Content-Type` header whenever `Response::set_headers` is called. This ensures that `mime_type` is always consistent with `Content-Type`. The other reason for going with this approach is it relies on `extract_mime_type`: afbcbf75ea/components/script/dom/headers.rs (L260-L261)
Besides the consistency argument, I also expect that we'll update the `extract_mime_type` method to conform with its specification.
Another option I explored was adding a `set_mime_type` member to `Response` and calling that with the mime type from `Metadata::content_type` in `FetchResponseListener::process_response`. I decided against this since it expanded the interface of `Response` and didn't have the same benefits of the first option.
Fixes#24628.
---
<!-- 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#24628.
<!-- Either: -->
- [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. -->
Fix loophole in messageport transfer
<!-- 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: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix#24600 (GitHub issue number if applicable)
<!-- 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. -->
Update xargo
Fixes https://github.com/servo/servo/issues/24766 (I already built and uploaded a package, and have a local build running using it)
I don't know why this fixes that issue, or why that issue turned up in the first place. But it seems to work!
r? @jdm
Split WPT macOS testing into many more chunks
## Before this
Before this PR, we had roughly as many chunks as available workers. Because the the number of test files is a poor estimate for the time needed to run them, we have significant variation in the completion time between chunks when testing one given PR.
https://github.com/servo/taskcluster-config/pull/9 adds a tool to collect this data. Here are two full runs of `test_wpt` before this PR:
https://community-tc.services.mozilla.com/tasks/groups/DBt9ki9gTdWmwAk-VDorzw
```
count 1, total 0:00:32, max: 0:00:32 docker 0:00:32
count 1, total 0:59:14, max: 0:59:14 macos-disabled-mac1 0:59:14
count 6, total 4:12:16, max: 1:01:14 macos-disabled-mac1 WPT 0:40:29 0:18:55 0:46:50 0:44:38 1:01:14 0:40:10
count 1, total 0:55:19, max: 0:55:19 macos-disabled-mac9 0:55:19
count 6, total 4:25:09, max: 1:01:40 macos-disabled-mac9 WPT 0:37:58 0:37:24 0:27:18 1:01:40 0:46:17 0:54:31
```
Times for a given chunk vary between 19 minutes and 61 minutes. Assuming no `try` testing, with Homu’s serial scheduling of `r+` testing this means that that worker sits idle for 42 minutes and our limited CPU resources are under-utilized.
When there *are* `try` PRs being tested however, they compete with each other and any `r+` PR for the same workers. If we get unlucky, a 61 minute task could only *start* after some other tasks have finished, Increasing the overall time-to-merge a lot.
## This
This PR changes the number of chunks to be significantly more than the number of available workers. When one of them finishes, that worker can pick up another one instead of sitting idle.
Now the ratio of number of tasks to number of workers doesn’t matter: the differences in run time between tasks becomes somewhat of an advantage and the distribution to workers evens out on average.
The number 30 is a bit arbitrary. A higher number reduces resource under-utilization, but increases the effect of per-task overhead. The git cache added in https://github.com/servo/servo/pull/24753 reduced that overhead, though.
Another worry I had was whether this would make worse the similar problem of unequal scheduling between processes within a task, where some CPU cores sit idle while the rest processes finish their assigned work.
This turned out not to be enough of a problem to negatively affect the total machine time:
https://community-tc.services.mozilla.com/tasks/groups/VnDac92HQU6QmrpzWPCR2w
```
count 1, total 0:00:48, max: 0:00:48 docker 0:00:48
count 1, total 0:39:04, max: 0:39:04 macos-disabled-mac9 0:39:04
count 31, total 4:03:29, max: 0:15:29 macos-disabled-mac9 WPT
0:07:26 0:08:39 0:04:21 0:07:13 0:12:47 0:10:11 0:04:01 0:03:36
0:10:43 0:12:57 0:04:47 0:04:06 0:10:09 0:12:00 0:12:42 0:04:40
0:04:24 0:12:20 0:12:15 0:03:03 0:07:35 0:11:35 0:07:01 0:04:16
0:09:40 0:05:08 0:05:01 0:06:29 0:15:29 0:02:28 0:06:27
```
(4h03min is even lower than above, but seems within variation.)
## After this
https://github.com/servo/servo/issues/23655 proposes automatically restarting failed WPT tasks, in case the failure is intermittent. With the test suite split into more chunks we have fewer tests per chunk, and therefore lower probability that a given one fails. Restarting one of them also causes less repeated work.
… since other time-sensitive tasks depend on them.
Note: we need to be careful with task priorities,
especially in worker pools with limited capacity,
since they are absolute and can cause starvation:
https://docs.taskcluster.net/docs/manual/tasks/priority
## Before this
Before this PR, we had roughly as many chunks as available workers.
Because the the number of test files is a poor estimate for the time
needed to run them, we have significant variation in the completion time
between chunks when testing one given PR.
https://github.com/servo/taskcluster-config/pull/9 adds a tool to collect
this data. Here are two full runs of `test_wpt` before this PR:
https://community-tc.services.mozilla.com/tasks/groups/DBt9ki9gTdWmwAk-VDorzw
```
count 1, total 0:00:32, max: 0:00:32 docker 0:00:32
count 1, total 0:59:14, max: 0:59:14 macos-disabled-mac1 0:59:14
count 6, total 4:12:16, max: 1:01:14 macos-disabled-mac1 WPT 0:40:29 0:18:55 0:46:50 0:44:38 1:01:14 0:40:10
count 1, total 0:55:19, max: 0:55:19 macos-disabled-mac9 0:55:19
count 6, total 4:25:09, max: 1:01:40 macos-disabled-mac9 WPT 0:37:58 0:37:24 0:27:18 1:01:40 0:46:17 0:54:31
```
Times for a given chunk vary between 19 minutes and 61 minutes.
Assuming no `try` testing, with Homu’s serial scheduling of `r+` testing
this means that that worker sits idle for 42 minutes
and our limited CPU resources are under-utilized.
When there *are* `try` PRs being tested however, they compete with
each other and any `r+` PR for the same workers. If we get unlucky,
a 61 minute task could only *start* after some other tasks have finished,
Increasing the overall time-to-merge a lot.
## This
This PR changes the number of chunks to be significantly more
than the number of available workers. When one of them finishes,
that worker can pick up another one instead of sitting idle.
Now the ratio of number of tasks to number of workers doesn’t matter:
the differences in run time between tasks becomes somewhat of an advantage
and the distribution to workers evens out on average.
The number 30 is a bit arbitrary. A higher number reduces resource
under-utilization, but increases the effect of per-task overhead.
The git cache added in https://github.com/servo/servo/pull/24753
reduced that overhead, though.
Another worry I had was whether this would make worse the similar problem
of unequal scheduling between processes within a task,
where some CPU cores sit idle while the rest processes finish their
assigned work.
This turned out not to be enough of a problem to negatively affect
the total machine time:
https://community-tc.services.mozilla.com/tasks/groups/VnDac92HQU6QmrpzWPCR2w
```
count 1, total 0:00:48, max: 0:00:48 docker 0:00:48
count 1, total 0:39:04, max: 0:39:04 macos-disabled-mac9 0:39:04
count 31, total 4:03:29, max: 0:15:29 macos-disabled-mac9 WPT
0:07:26 0:08:39 0:04:21 0:07:13 0:12:47 0:10:11 0:04:01 0:03:36
0:10:43 0:12:57 0:04:47 0:04:06 0:10:09 0:12:00 0:12:42 0:04:40
0:04:24 0:12:20 0:12:15 0:03:03 0:07:35 0:11:35 0:07:01 0:04:16
0:09:40 0:05:08 0:05:01 0:06:29 0:15:29 0:02:28 0:06:27
```
(4h03min is even lower than above, but seems within variation.)
## After this
https://github.com/servo/servo/issues/23655 proposes automatically
restarting failed WPT tasks, in case the failure is intermittent.
With the test suite split into more chunks we have fewer tests per chunk,
and therefore lower probability that a given one fails.
Restarting one of them also causes less repeated work.
Use TimerHandler IDL union type
<!-- 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#20700
<!-- Either: -->
- [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. -->
