Fixes the following assertion from `tests/wpt/web-platform-tests/html/
browsers/origin/cross-origin-objects/cross-origin-objects.html`:
assert_equals(Object.keys(win.location).length, 0,
"Object.keys() gives the right answer for cross-origin Location");
Setting the lazy proto option allows proxy handlers to provide dynamic
prototype objects. This is necessary for the customization of
`ProxyTraps::{get,set}PrototypeOf` to actually take effect.
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
<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. -->
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. -->
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
> 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.
Update toolchain to nightly-2021-05-18
The nightly-2021-03-12 toolchain doesn't have RLS on Windows. This
breaks code completion in Visual Studio Code because the rust plugin
picks up the project toolchain.
RLS is available in all tier one platforms in nightly-2021-05-18 per:
https://rust-lang.github.io/rustup-components-history/
Signed-off-by: Dominic Cooney <dominic.cooney@gmail.com>
<!-- Please describe your changes on the following line: -->
Update toolchain to nightly-2021-05-18
---
<!-- 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 (note, except tabs/spaces issue in an unrelated file... happy to fix in this PR)
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because changing the toolchain, covered by existing tests
<!-- 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. -->
ref_slice::ref_slice is deprecated in ref_slice-1.2.1,
because it's redundant with std since rust 1.28.
Signed-off-by: Adrian Willenbücher <willenbuecher@xq-tec.com>
