The concrete types of `[Global]` DOM interfaces have `origin` methods,
which were used before this commit. Some of them just delegate to
`GlobalScope::origin` while others are implemented differently. This
commit changes the created principals objects' associated origins in the
following way:
- `DedicatedWorkerGlobalScope` - was `WorkerGlobalScope::worker_url`
- `DissimilarOriginWindow` - no change
- `PaintWorkletGlobalScope` - no change
- `ServiceWorkerGlobalScope` - was `ServiceWorkerGlobalScope::scope_url`
- `TestWorkletGlobalScope` - no change
- `Window` - no change
Set `DedicatedWorkerGlobalScope`'s origin correctly
<https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers>
> To **set up a worker environment settings object**, given a JavaScript execution context *execution context* and environment settings object *outside settings*: [...]
>
> 4. Let *settings object* be a new environment settings object whose algorithms are defined as follows:
>
> **The origin** Return a unique opaque origin if *worker global scope*'s url's scheme is "data", and *inherited origin* otherwise.
---
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model>
> 10.2.4 Processing model
>
> When a user agent is to run a worker for a script with `Worker` or
> `SharedWorker` object `worker`, [...] it must run the following steps.
>
> [...]
>
> 8. Set up a worker environment settings object with `realm execution
> context` and `outside settings`, and let `inside settings` be the
> result.
<https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers>
> To **set up a worker environment settings object**, given a JavaScript
> execution context `execution context` and environment settings object
> `outside settings`:
>
> 1. Let `inherited origin` be `outside settings`'s origin.
>
> 2. Let `realm` be the value of `execution context`'s Realm component.
>
> 3. Let `worker global scope` be `realm`'s global object.
>
> 4. Let `settings object` be a new environment settings object whose
> algorithms are defined as follows:
>
> **The origin** Return a unique opaque origin if `worker global
> scope`'s url's scheme is "data", and `inherited origin` otherwise.
Update mozjs
- <https://github.com/servo/rust-mozjs/pull/548>
---
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it introduces no behavioral changes
Properly implement HTMLProgressElement DOM code
<!-- Please describe your changes on the following line: -->
The DOM code for HTMLProgressElement have been implemented, according to https://html.spec.whatwg.org/multipage/form-elements.html#the-progress-element . As mentioned in #23201, tests already exists for this element in tests/wpt/web-platform-tests/html/semantics/forms/the-progress-element/, which now passes (tested on Linux).
---
<!-- 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. -->
Create only one compartment for each script thread (agent)
Documents in the same [agent][1] can share and exchange JS and DOM objects freely, so putting them in separate compartments would require almost every instance of `Dom` to be capable of handling cross-compartment references.
[1]: https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-formalism
---
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because I think there's already a wide test coverage for same-origin-domain JS object passing, albeit this requires Servo to be built with `--debug-mozjs` for the errors to be (reliably) observable
bootstrap: add support for Ubuntu 21.04
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
<!-- Please describe your changes on the following line: -->
Allow `./mach bootstrap` to run on Ubuntu 21.04
---
<!-- 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)~ (Happy to create an issue retroactively if that's preferable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they can be trivially tested by running `./mach bootstrap` on Ubuntu 21.04
<!-- 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 struct shorthand initialization.
<!-- 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
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they don't really change any logic
<!-- 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. -->
Bump `time` to latest `v0.1.x` 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: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because they just bump dependencies (I say this now)
<!-- 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. -->
add NixOS support to mach and automatically re-launch mach in nix-shell
<!-- Please describe your changes on the following line: -->
This is a followup for #28454 which adds nixos support directly to mach, saving the user from typing `nix-shell` everytime
---
<!-- 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 #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they just extend mach
<!-- 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. -->
Remove `settings.json` from `.gitignore`.
Also add `Brewfile.lock.json` to the list of ignored files.
Signed-off-by: teymour-aldridge <teymour.aldridge@icloud.com>
<!-- 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 #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because they do not modify any code files
<!-- 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. -->
Implement `offset{Left,Top,Width,Height,Parent}` in Layout 2020
Implements `HTMLElement#offset{Left,Top,Width,Height,Parent}` ([CSSOM View Module §7]) in Layout 2020.
[CSSOM View Module §7]: https://www.w3.org/TR/2016/WD-cssom-view-1-20160317/#extensions-to-the-htmlelement-interface
---
- [x] `./mach build -d`**` --with-layout-2020`** does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
---
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because the implemented items are already extensively used by the test harness for layout assertion
Fix hang-ups in `background_hang_monitor` tests
---
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [x] These changes fix#28270, #27191 and random failures in the CI pipeline
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
> However, as it turns out, `crossbeam-channel`'s channels don't drop
> remaining messages until all associated senders *and* receivers are
> dropped. This means the exit signal won't be delivered as long as
> there's at least one `HangMonitorRegister` or
> `BackgroundHangMonitorChan` maintaining a copy of the sender. To work
> around this and guarantee a rapid delivery of the exit signal, the
> sender is wrapped in `Arc`, and only the worker thread maintains a
> strong reference, thus ensuring both the sender and receiver are
> dropped as soon as the worker thread exits.
> There's a race condition between the reception of
> `BackgroundHangMonitorControlMsg::Exit` and `MonitoredComponentMsg::
> Register`. When the worker receives `Exit`, it stops receiving
> messages, and any remaining messages (including the
> `MonitoredComponentMsg::Register` we sent) in the channel are dropped.
> Wrapping `exit_signal` with this RAII wrapper ensures the exit signal
> is delivered even in such cases.
This should (hopefully) eliminate the intermittent hang-ups in the test
case `test_hang_monitoring_exit_signal` for good.
