The condition for exposing a cross-origin setter should be `CrossOriginWritable`, not `CrossOriginReadable`
Fixes `Location#href` being inaccessible from a cross-origin document.
---
- [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)
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
The expression `crossOriginIframe.contentWindow.location.href = "new
href"` takes the following steps: (1) Get the setter for `href` by
invoking `[[GetOwnProperty]]` on `crossOriginIframe.contentWindow.
location`. (2) Call the setter, passing `crossOriginIframe.
contentWindow` and `"new href"`. Since the target `Location` is cross
origin, getting the setter succeeds only if the `CrossOriginWritable`
extended attribute is present on the `href` attribute, and it's present.
However, instead of `CrossOriginWritable`, `CrossOriginReadable` was
checked mistakenly.
Since `Location#href` has `CrossOriginWritable` but not
`CrossOriginReadable`, this bug rendered `Location#href` inaccessible
from a cross-origin document.
This likely originates from a bug that existed in the specification[1].
A `src`-less iframe would fire two `load` events when implemented
according to an affected version of the specification.
[1]: f2839722e1
The initial document creation does not involve navigation, and it would
cause a confusion if this was done by a function which has `navigation`
in its name. This commit renames `navigate_or_reload_child_browsing_
context` to `start_new_pipeline`, and introduces a new function which
has the original name and is dedicated to handle navigation.
Implement `Location`'s custom internal methods
This PR partly resurrects #16501 and introduces the use of principals object to associate objects and Realms with origins. Using this infrastructure, this PR implements [the custom internal methods][1] of the `Location` interface, which is "maybe-cross-origin".
Unimplemented/incomplete things:
- Other maybe-cross-origin interfaces, namely `WindowProxy` and `DissimilarWindowLocation`, aren't implemented correctly yet (causing most test cases of `tests/wpt/web-platform-tests/html/browsers/origin/cross-origin-objects/cross-origin-objects.html` to fail).
- `WindowProxy`: #28556
- [The "perform a security check" operation][2] and `Location`'s non-cross-origin properties' relevant `Document` origin checks aren't implemented either (not sure if they are covered by the existing tests).
- There are a slight deviation from the standard and inefficiency in `CrossOriginGetOwnPropertyHelper`'s current implementation.
- #28557
[1]: https://html.spec.whatwg.org/multipage/#the-location-interface
[2]: https://html.spec.whatwg.org/multipage/browsers.html#integration-with-idl
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#16243 and make some progress in #2382
---
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
There are code fragments in `(Method|Attr)Definer.generateArray` that
are much alike. This commit refactors them into a new method of
`PropertyDefiner` named `generateUnguardedArray` (in contrast to the
existing method `generateGuardedArray`).
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.
The Linux kernel imposes a 15-byte limit on thread names[1]. This means
information that does not fit in this limit, e.g., the pipeline ID of
layout and script threads, is lost in a debugger and profiler (see the
first column of the table below).
This commit shortens the thread names used in Servo to maximize the
amount of information conveyed. It also rectifies some inconsistencies
in the names.
| Before | After |
|-------------------|-------------------|
| `BluetoothThread` | `Bluetooth` |
| `CanvasThread` | `Canvas` |
| `display alert d` | `AlertDialog` |
| `FontCacheThread` | `FontCache` |
| `GLPlayerThread` | `GLPlayer` |
| `HTML Parser` | `Parse:www.examp` |
| `LayoutThread Pi` | `Layout(1,1)` |
| `Memory profiler` | `MemoryProfiler` |
| `Memory profiler` | `MemoryProfTimer` |
| `OfflineAudioCon` | `OfflineACResolv` |
| `PullTimelineMar` | `PullTimelineDat` |
| `ScriptThread Pi` | `Script(1,1)` |
| `WebWorker for h` | `WW:www.example.` |
| `ServiceWorker f` | `SW:www.example.` |
| `ServiceWorkerMa` | `SvcWorkerManage` |
| `Time profiler t` | `TimeProfTimer` |
| `Time profiler` | `TimeProfiler` |
| `WebGL thread` | `WebGL` |
| `Choose a device` | `DevicePicker` |
| `Pick a file` | `FilePicker` |
| `Pick files` | `FilePicker` |
[1]: https://stackoverflow.com/questions/5026531/thread-name-longer-than-15-chars
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.
