* Replace `time` with `chrono` in `script/animation_timeline`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/script_thread.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` and `chrono` in `script/script_thread.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/script_runtime.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/script_runtime.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/workerglobalscope.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `chrono` in `script/dom/workerglobalscope.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/htmlmedialelement.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/htmlmedialelement.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/globalscope.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `chrono` in `script/dom/globalscope.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/htmlformelement.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Replace `time` with `std::time` in `script/dom/htmlformelement.rs`
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
* Increase precision of animation timeline
* Some fixes
Use Instant a bit more and stop using chrono. Do not transition
`navigation_start_precise` to Instant yet as we need to coordinate this
across all crates.
---------
Signed-off-by: Auguste Baum <auguste.apple@gmail.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* Remove script_plugins
* Use crown instead of script_plugins
* crown_is_not_used
* Use crown in command base
* bootstrap crown
* tidy happy
* disable sccache
* Bring crown in tree
* Install crown from tree
* fix windows ci
* fix warning
* fix mac
libscript_plugins.dylib is not available anymore
* Update components/script/lib.rs
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* Update for nightly-2023-03-18
Mostly just based off https://github.com/servo/servo/pull/30630
* Always install crown
it's slow only when there is new version
* Run crown test with `mach test-unit`
* Small fixups; better trace_in_no_trace tests
* Better doc
* crown in config.toml
* Fix tidy for real
* no sccache on rustc_wrapper
* document rustc overrides
* fixup of compiletest
* Make a few minor comment adjustments
* Fix a typo in python/servo/platform/base.py
Co-authored-by: Samson <16504129+sagudev@users.noreply.github.com>
* Proper test types
* Ignore tidy on crown/tests
---------
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* Update mozjs
* moztools4 in bootstrap
* no autoconf
* tidy
* switch to servo-build-deps
* update mozjs for real
* glue mozjs
* fmt
* move to servo/mozjs
* Fix race condition in Worker destruction
During shutdown, the main script thread calls
JS_RequestInterruptCallback(cx) for each worker thread it owns
where cx is the JSContext* created for that worker.
Although JS_RequestInterruptCallback is safe to call
from threads other than the worker thread, it is possible
the JSContext* has already been destroyed
For example, as noted in #30022, since the main thread sets
the worker's `closing` flag to true to signal termination before it
calls JS_RequestInterruptCallback, we can have a race condition
where the worker exits its event loop when `closing` flags is set
and then it (worker thread) destroys its own JSContext and JSRuntime.
When the main thread resumes, it will call
JS_RequestInterruptCallback for the worker's context, leading to
a use-after-free bug.
This patch solves this issue by improving the existing
`ContextForRequestInterrupt` abstraction used for sharing the Worker's
associated JSContext* with the parent script thread.
Instead of simply wrapping a plain `*mut JSContext`, we now wrap the
`*mut JSContext` in a nullable mutex i.e Mutex<Option<*mut JSContext>>
The mutex lock needs to be held by the parent thread when it
calls JS_RequestInterruptCallback.
Similary, before the worker destroys its JSContext, it locks and
sets the Option to None, signaling that the JSContext can no longer
be used for interrupting the worker.
This patch also fixes the issue in #30052 by enforcing the use
of ContextForRequestInterrupt abstraction which ensures the correct
JSContext is used by the main thread when Worker.terminate is called.
Fixes#30022, #30052
* Fix Worker.importScripts to handle termination
Fixing #30052 uncovered this issue in the implementation
of `importScripts` method. After the fix for #30052,
the WPT test `/workers/Worker-terminate-forever-during-evaluation.html`
started to crash because when evaluation doesn't succeed
`importScripts` always returns Error::JSFailed code to the caller,
which indicates that there is a Dom/JS exception to be thrown. However,
this is not true when the script is terminated, which causes
the generated binding layer for 'importScript` to fail
the assertion that there is a pending exception.
This patch makes `importScripts` work similar to the [logic that
evaluates the top-level script][1] of the Worker - it simply prints
`evaluate_script failed - (terminated)' if the worker is terminating
[1]: 3fea90a231/components/script/dom/workerglobalscope.rs (L434)
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
