It's technically safe to do because of `#[repr(transparent)]` and is a
prerequisite of having `ServoJSPrincipalsRef: Copy`, but I guess it's
not worth an `unsafe` block.
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. -->
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>
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>
