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. -->
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 process of decoding the network byte stream to Unicode is backed by
an instance of `encoding_rs::Decoder`, which will switch the encoding it
uses if it finds a BOM in the byte stream. However, this change in
encoding is not communicated back to the caller and so
`document.characterSet` gives the wrong result. This change fixes that.
See whatwg/html#5359 and whatwg/encoding#203 for the spec-level backing
for this change.
Signed-off-by: Andreu Botella <abb@randomunok.com>
