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
This update pulls in improvements on mozjs that now removes the need to
pass pointers to CompileOptionsWraper::new(), allows NewProxyObject to
now accept a Singleton bool and JSClass and removes an unsafe
Handle::new usage.
Introduce dynamic module
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#25439
- [x] There are tests for these changes
Web developers can use `Dynamic Import` in a classic script; thus, we
need to save the script's private reference so that we can reuse it when
we're going to fetch a dynamic import module for a classic script.
Besides, because it's possible to use different executing context for a
dynamic import module (like `dynamic-import/string-compilation-other-document.html` WPT test),
we can't initialize a module owner at the timing of `SetScriptPrivate`;
thus, if the private module script doesn't hold an owner, we'll use a
DynamicImport owner for it.
Ensure clean shutdown of JS threads
<!-- Please describe your changes on the following line: -->
FIX https://github.com/servo/servo/issues/26685
FIX https://github.com/servo/servo/issues/26996
FIX https://github.com/servo/servo/issues/9672FIX#27027
---
<!-- 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 ___
<!-- 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. -->
Fix building with --feature js_backtrace
This PR fixes an build error that I ran into when using the `--features js_backtrace` flag.
In particular, the error I ran into was this:
```
error[E0061]: this function takes 2 arguments but 1 argument was supplied
--> components\script\dom\bindings\error.rs:113:45
|
113 | let js_stack = stack.and_then(|s| s.as_string(None));
| ^^^^^^^^^ ---- supplied 1 argument
| |
| expected 2 arguments
```
It seems that the `mozjs` crate updated the [`as_string()` method on `CapturedJSStack`](https://doc.servo.org/mozjs/rust/struct.CapturedJSStack.html#method.as_string) to take two parameters. I've chosen to use `StackFormat::Default` because that will presumably preserve the original intended behavior.
I additionally had to make the block wrapping the feature unsafe as I ran into a "must be marked as unsafe to call unsafe code" build error after fixing the above issue. Seems that this commit (0703a1ad6d) forgot that part.
#### Other Notes
After these changes, I was able to build but ran into an access violation error during runtime. When a JS error hit [`throw_dom_exception()`](https://github.com/servo/servo/blob/master/components/script/dom/bindings/error.rs#L109) and the JS stack was pulled, some sort of issue was hit inside mozjs and [`MOZ_NoReturn()`](bdccbdc656/mozjs/mfbt/Assertions.h (L235)) was called, which will obviously cause an issue.
It is worth noting that this only happened on my test platform (Hololens 2) and not on MacOS or in the Hololens 2 emulator. Additionally, the debug logs were not particularly helpful at identifying the culprit. Maybe it is worth making a full issue for?
Here's the full details:
Error message:
```
Exception thrown at 0x00007FFBCDD16784 (simpleservo.dll) in ServoApp.exe: 0xC0000005: Access violation writing location 0x0000000000000000.
```
Stack Trace:
```
simpleservo.dll!MOZ_NoReturn(int aLine) Line 236
at E:\Projects\Yeti\servo\target\aarch64-uwp-windows-msvc\debug\build\mozjs_sys-aa48eb6c20c205d4\out\build\dist\include\mozilla\Assertions.h(236)
simpleservo.dll!js::SavedStacks::insertFrames(JSContext * cx, JS::MutableHandle<js::SavedFrame *> frame, mozilla::Variant<JS::AllFrames,JS::MaxFrames,JS::FirstSubsumedFrame> && capture) Line 0
at E:\.cargo\git\checkouts\mozjs-fa11ffc7d4f1cc2d\9a6d8fc\mozjs\js\src\vm\SavedStacks.cpp(0)
simpleservo.dll!js::SavedStacks::saveCurrentStack(JSContext * cx, JS::MutableHandle<js::SavedFrame *> frame, mozilla::Variant<JS::AllFrames,JS::MaxFrames,JS::FirstSubsumedFrame> && capture) Line 1292
at E:\.cargo\git\checkouts\mozjs-fa11ffc7d4f1cc2d\9a6d8fc\mozjs\js\src\vm\SavedStacks.cpp(1292)
simpleservo.dll!JS::CaptureCurrentStack(JSContext * cx, JS::MutableHandle<JSObject *> stackp, mozilla::Variant<JS::AllFrames,JS::MaxFrames,JS::FirstSubsumedFrame> && capture) Line 5926
at E:\.cargo\git\checkouts\mozjs-fa11ffc7d4f1cc2d\9a6d8fc\mozjs\js\src\jsapi.cpp(5926)
simpleservo.dll!mozjs::rust::CapturedJSStack::new(mozjs::rust::RootedGuard<mut mozjs_sys::generated::root::JSObject*> cx, core::option::Option<u32> guard) Line 1337
at E:\.cargo\git\checkouts\rust-mozjs-8611526964119dd6\28248e1\src\rust.rs(1337)
simpleservo.dll!script::dom::bindings::error::throw_dom_exception(script::script_runtime::JSContext cx, script::dom::globalscope::GlobalScope * global, script::dom::bindings::error::Error result) Line 114
at E:\Projects\Yeti\servo\components\script\dom\bindings\error.rs(114)
```
Repro:
1. Make a build on Windows for the Hololens 2.
- This is the command I used: `C:\Python27\python.exe mach build -d --uwp --win-arm64 --features js_backtrace`
2. Open the project in Visual Studio.
3. Change the default URL in `DefaultUrl.h` to `"http://yeticgi.casualos.com/?story=test1&pagePortal=home"`.
- Note the lack of HTTPS. There's a separate issue that causes a websocket error. Was trying to debug when I ran into this issue.
- The same issue occurs if you load from a build of this [this repository](https://github.com/casual-simulation/casualos). Follow the instructions in [`DEVELOPERS.md`](https://github.com/casual-simulation/casualos/blob/develop/DEVELOPERS.md) if you do.
2. Run on the [Hololens 2 via Visual Studio](https://docs.microsoft.com/en-us/windows/mixed-reality/using-visual-studio#deploying-an-app-over-wi-fi---hololens-2).
- If the default URL doesn't take effect, you may have to uninstall the app from the Hololens 2 and reinstall.
3. Wait for it to load and stop at a breakpoint for `SavedStacks.cpp`.
- It will say the source cannot be found but its actually because the breakpoint doesn't have a related line in the source code.
- If you continue then it will run into the access violation exception.
---
<!-- 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
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they fix a build error.
<!-- 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. -->
- mozjs::jsapi::CapturedJSStack::as_string() (https://doc.servo.org/mozjs/rust/struct.CapturedJSStack.html#method.as_string) was updated to accept a second parameter which specifies which Stacktrace format to use. The default has been specified to preserve the (presumably) original behavior.
- The related code has also been placed in an unsafe block since the capture_stack macro calling the unsafe mozjs::jsapi::CapturedJSStack::new() function. Seems that this commit (0703a1ad6d) forgot this part.
Add GPUSampler and GPUTextureView to BindingResources and update wgpu-core
<!-- Please describe your changes on the following line: -->
This also completes validation for `GPUBindGroup` and `GPUBindGroupLayout`.
`entry_map` is stored in `GPUBindGroupLayout` for validating `createBindGroup()`.
r?@kvark
---
<!-- 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
- [ ] 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. -->
