Fix panic on vimeo.com
The only time we end up enqueuing a promise reaction job with a null incumbent global argument is when SpiderMonkey does some weird stuff behind the scenes for its JS Debugger support (based on https://searchfox.org/mozilla-central/rev/2c1092dc68c63f7bad6da6a03c5883a5ab5ff2ca/js/src/builtin/Promise.cpp#3168). This commit works around that case and adds a regression test so we don't forget about that in the future.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#26930
- [x] There are tests for these changes
Enable Atomics.wait in a dedicated worker agent
<!-- Please describe your changes on the following line: -->
FIX#25191
---
<!-- 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. -->
Accept transfer argument for StructuredCloneData::write
Allow structured clone reads to return a boolean
Add Transferable trait
Add basic skeletons to MessagePort
Implement transfer and transfer-receiving steps on MessagePort
Use transfer and transfer_receive in StructuredClone callbacks
Implement MessageChannel
Freeze the array object for the MessageEvent ports attribute
Implement transfer argument on window.postMessage
Use ReentrantMutex instead for MessagePortInternal
Accept origin as a parameter in dispatch_jsval
Fix BorrowMut crash with pending_port_message
Detach port on closure and check for detached during transfer
Enable webmessaging tests
fix webidl
fix
Assert incumbent global is always some in get_incumbent_global hook
While working on module script, I'd like to use Promise with a custom
callback with type `Box<dyn TaskBox>` which means we didn't use web API
callbacks as native handlers. However, we'll get a panic from
`enqueue_promise_job` and the panic says we have a `null` incumbent
global. The main problem here is, the Promise API is strongly tied to JS
engine and it always assumes there's a meaningful answer for "what
specific global is this promise associated with". So, when I don't use
the Promise for a specific web API, our engine cannot find a proper
incumbent global for us so that we get the `null` incumbent global
panic.
To make us catch this case easier in the future, we should add the
assertion inside `get_incumbent_global` hook so that we can know this
quickly next time.
Ref: https://mozilla.logbot.info/servo/20190807#c16525481
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it should just add assertion inside the hook
<!-- 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23930)
<!-- Reviewable:end -->
While working on module script, I'd like to use Promise with a custom
callback with type `Box<dyn TaskBox>` which means we didn't use web API
callbacks as native handlers. However, we'll get a panic from
`enqueue_promise_job` and the panic says we have a `null` incumbent
global. The main problem here is, the Promise API is strongly tied to JS
engine and it always assumes there's a meaningful answer for "what
specific global is this promise associated with". So, when I don't use
the Promise for a specific web API, our engine cannot find a proper
incumbent global for us so that we get the `null` incumbent global
panic.
To make us catch this case easier in the future, we should add the
assertion inside `get_incumbent_global` hook so that we can know this
quickly next time.
Ref: https://mozilla.logbot.info/servo/20190807#c16525481
Unify the task source and task canceller API
To do so, I created a struct `TaskManagement(TaskSource,
TaskCanceller)` and made `*_task_source` return that instead of just
the task source.
Next, I refactored all places in which `task_canceller` by basically
removing them in favour of a previously called `*_task_source`.
I tried to make `task_canceller` a private method in `Window`, with the
hope of enforcing the use of `*_task_source`. However, it's used in
components/script/dom/globalscope.rs:575 in such a way that will make it
harder to avoid. I decided to leave it that way.
It'd be possible to unify `*_task_source` in such a way that we would
have only one method. However, I decided not to do it because one of the
`TaskSource` implementations is special:
`history_traversal_task_source`. Not wanting to over complicate things,
I decided to leave the structure this way.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#21154 (github issue number if applicable).
- [x] These changes do not require tests because it's refactoring code that should already be tested.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21804)
<!-- Reviewable:end -->
Clear refcounted promise before dropping JSRuntime
Not sure if this is the right solution?
I also tried to `impl Drop for LiveDOMReferences` but it's still executed after dropping JSRuntime.
So, maybe we should clear it before dropping the JSRuntime?
cc @jdm @asajeffrey
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#21331 .
- [x] There are tests for these changes; the status of `fetch/cross-origin-resource-policy/fetch-in-iframe.html` will be `OK`
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21988)
<!-- Reviewable:end -->
