script: fix BorrowError in (new Blob).slice(0,0).text()
When getting the text of a sliced Blob, we call GlobalScope.get_blob_url_id, which borrows the blob_state field mutably and calls the get_blob_size method (aka [Blob#size](https://w3c.github.io/FileAPI/#dfn-size)), which tries to borrow the same field immutably, causing a panic.
This patch inlines the relevant parts of get_blob_size into get_blob_url_id, so we can reuse the mutable borrow.
* /FileAPI/Blob-methods-from-detached-frame.html was 4/4 FAIL, will be 4/4 PASS once #29396 also lands
* /fetch/api/basic/scheme-blob.sub.any.html was CRASH, now 10/17 PASS and 7/17 FAIL
* /fetch/api/basic/scheme-blob.sub.any.worker.html was CRASH, now 10/17 PASS and 7/17 FAIL
---
<!-- 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
- [x] These changes fix#29450
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because ___
Add a "shmem" feature to selectors to avoid publishing that dependency
<!-- Please describe your changes on the following line: -->
Hopefully as a way to help #29105, this PR adds a `shmem` feature to the selectors crate. This is so that the crate can be released with that feature off by default, as the `ToShmem` derives are only of interest to Servo, I think.
All the places where servo's source code includes the selectors crate are made to turn on this feature.
#26488 Move worklet drop implementation into single droppable member
Signed-off-by: Benjamin Freist <bfreist@soundhound.com>
<!-- Please describe your changes on the following line: -->
Hey @jdm ,
is this issue still free? I would like to start contributing to servo.
This patch is straight from PR 28302, I thought it would be good to start with a small part, I hope that's ok.
---
<!-- 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
- [x] These changes do not require tests because they will be checked by the compiler.
<!-- 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. -->
Fixes the test case `/_mozilla/css/css-transition-cancel-event
.html`, which was failing under a specific circumstance.
The observed sequence of events during the failing test run looks like
this:
1. Transitions start in `div1` and `div2`.
2. `div1` generates a `transitionend` event.
3. The `transitionend` event handler removes `div2` from DOM, cancelling
its ongoing transition.
4. `div2` is supposed to generate a `transitioncancel` event in a timely
manner, which it does not. The test fails as a result.
What is going on here? Here's a possible explaination:
1. During one invocation of `ScriptThread::handle_msgs`...
2. In step 2, `ScriptThread::update_animations_send_events` -> `Document
::update_for_new_timeline_value` detects the completion of the
transition, and in response, pends the `transitionend` event.
3. In step 3, `ScriptThread::update_animations_send_events` ->
`Animations::send_pending_events` calls the `transitionend` handler.
4. The `transitionend` event handler removes `div2`, thereby cancelling
its ongoing transition and triggering a reflow.
5. Reflow takes place. During this, `Animations::do_post_reflow_update`
-> `Animations::handle_canceled_animations` pends the
`transitioncancel` event (precursor to step 4).
6. Having discovering that there was no running animation, `Animations::
do_post_reflow_update` calls `self.update_running_animation_presence
(_, false)`, which sends `AnimationState::NoAnimationsPresent`.
7. The invocation of `ScriptThread::handle_msgs` ends, and another
starts. It blocks waiting for events.
8. Meanwhile, the compositor receives `AnimationState::
NoAnimationsPresent` and stops further generation of animation ticks.
9. With no events to wake it up, the script thread is stuck waiting
despite having the pending `transitioncancel` event (step 4).
The HTML specification [says][1] that "an event loop must continually
run [...] as long as it exists" and does not say it can block if there
is nothing to do. Blocking is merely optimization in a user agent
implementation. Pending animation-related events must be processed every
time a "rendering opportunity" arises unless the user agent has a reason
to believe that it "would have no visible effect".
Skipping the processing of animation-related events would have visible
effect if such events are indeed present. The correct implementation in
Servo, therefore, would be to request more animation ticks so that such
events are processed in a subsequent tick.
[1]: https://html.spec.whatwg.org/multipage/#event-loop-processing-model
This commit reverses the order of the `send_pending_events` and
`update_animation_timeline` calls in `ScriptThread::update_animations_
send_events` so that animation-related events pended by the latter are
processed by the former.
The new calling order is more compliant with the "update animations and
send events" algorithm steps from [the Web Animations specification][1].
The old implementation was prone to blocking for an indefinite period
while holding pending events. Due to complex interaction with other
events and timing behavior, I was only able to reproduce the problem
under the following conditions:
- *The `maybe_observe_paint_time` call in `LayoutThread::compute_abs_
pos_and_build_display_list` is removed from the code*. While
performance events may seem irrelevant to the issue, they would
bombard the script thread with events. *Any* extra messages received
would unblock the event loop and prevent the manifestation of the
issue. (But, of course, we aren't supposed to count on that to avoid
the issue.)
- Servo is running in a headless mode, which somehow makes it less
likely for the script thread to receive a `TickAllAnimations` event
after sending `AnimationState::NoAnimationsPresent`.
With the above conditions met and the stars aligned, you can reproduce
the problem by running the WPT test `/css/css-transitions/events-001.
html`.
[1]: https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events
- Also updates raqote to latest with an upgrade of font-kit to 0.11
applied on as a patch
- Update lyon_geom to the latest version
Major change:
- All matrices are now stored in row major order. This means that
parameters to rotation functions no longer should be negated.
- `post_...()` functions are now named `then()`. `pre_transform()` is removed,
so `then()` is used and the order of operations changed.
Replace use of the deprecated RUST_SYMBOL_TO_JSID by SymbolId
<!-- Please describe your changes on the following line: -->
A simple replacement of a deprecated function, according to changes in https://github.com/servo/mozjs/pull/315
That removes the only build warning I saw when doing a clobber.
---
<!-- 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
- [ X] These changes do not require tests because no behavior change is expected.
<!-- 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. -->
Allow displaying content with "application/json" mime type
For me this allows the WPT test
performance-timeline/tentative/include-frames-one-remote-child.sub.html
to match expected results. The wptserver is sending a 404 JSON response
because the URL that the test requests is not found.
<!-- Please describe your changes on the following line: -->
---
<!-- 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
- [x] These changes fix#29136.
- [x] There are tests for these changes.
<!-- 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. -->
For me this allows the WPT test
performance-timeline/tentative/include-frames-one-remote-child.sub.html
to match expected results. The wptserver is sending a 404 JSON response
because the URL that the test requests is not found.
When turning DOM exceptions into `ErrorInfo` always try to stringify
the JavaScript value, even if it's an object that isn't a `DOMException`
or native exception. This means that exceptions that extend the `Error`
prototype are now stringified. The result is that test output for WPT
global assertion failures is more useful. For instance for the test
include-frames-from-child-same-origin-grandchild.sub.html:
Before:
```
uncaught exception: unknown (can't convert to string)
```
After:
```
uncaught exception: Error: assert_equals: expected 4 but got 3
```
Fix intermittency when loading poster images
Wait until a poster image is cached to in order to unblock document load. If not, the document may continue loading before the image is ready to use, leading to intermittency in test output. Now load is unblocked when getting the ImageResponse from the cache, which allows the code to properly unblock the load when the entire load fails or succeeds.
This reveals several false passes in the `object-view-box` test suite which were very flaky.
<!-- Please describe your changes on the following line: -->
---
<!-- 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
- [x] These changes fix#29204.
- [x] These changes fix#29188.
- [x] These changes fix#29179.
<!-- Either: -->
- [x] There are tests for these changes
<!-- 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. -->
- Mark some instances of unused fields and variables as as allowed,
when they are used for memory management.
- Remove the use of some deprecated function.s
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Wait until a poster image is cached to in order to unblock document load. If
not, the document may continue loading before the image is ready to use,
leading to intermittency in test output. Now load is unblocked when
getting the ImageResponse from the cache, which allows the code to
properly unblock the load when the entire load fails or succeeds.
This reveals several false passes in the `object-view-box` test suite
which were very flaky.
Fixes#29204.
Fixes#29188.
Fixes#29179.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Convert Web IDL void to undefined
<!-- Please describe your changes on the following line: -->
Thanks to my tool https://github.com/saschanaz/gecko-webidl🙌
Build is failing on my current VS2022+Python 3.10 environment, but the IDL tests are passing anyway, so...
---
<!-- 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
- [x] These changes fix#27660
<!-- Either: -->
- [x] There are tests for these changes
<!-- 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. -->
https://fetch.spec.whatwg.org/#concept-response-clone
If the header guard of the response to clone is `immutable`, then copying the headers to the new response will fail with `Guard is immutable` unless we ensure the guard is copied _after_ the headers.
8650794391/components/script/dom/response.rs (L331-L334)
fn Append(&self, name: ByteString, value: ByteString) -> ErrorResult {
// Step 1
let value = normalize_value(value);
// Step 2
let (mut valid_name, valid_value) = validate_name_and_value(name, value)?;
valid_name = valid_name.to_lowercase();
// Step 3
if self.guard.get() == Guard::Immutable {
return Err(Error::Type("Guard is immutable".to_string()));
}
Need to ensure the passed in pointers are non-null prior to using them unchecked. Seeing sporadic crashes:
```
Stack trace for thread "Script(2,36)"
0: backtrace::backtrace::libunwind::trace
at /Users/navgattu/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.63/src/backtrace/libunwind.rs:93:5
backtrace::backtrace::trace_unsynchronized
at /Users/navgattu/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.63/src/backtrace/mod.rs:66:5
1: <servo::backtrace::Print as core::fmt::Debug>::fmt
at /Users/navgattu/Documents/dev-git/servo/ports/winit/backtrace.rs:53:13
2: core::fmt::write
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/core/src/fmt/mod.rs:1117:17
3: std::io::Write::write_fmt
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/std/src/io/mod.rs:1667:15
4: servo::backtrace::print
at /Users/navgattu/Documents/dev-git/servo/ports/winit/backtrace.rs:17:5
5: servo::crash_handler::install::handler
at /Users/navgattu/Documents/dev-git/servo/ports/winit/crash_handler.rs:25:21
6: __sigtramp
7: core::ptr::non_null::NonNull<T>::as_ref
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/core/src/ptr/non_null.rs:317:20
8: alloc::rc::Rc<T>::inner
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/alloc/src/rc.rs:332:18
<alloc::rc::Rc<T> as core::clone::Clone>::clone
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/alloc/src/rc.rs:1479:9
9: <servo_url::origin::MutableOrigin as core::clone::Clone>::clone
at /Users/navgattu/Documents/dev-git/servo/components/url/origin.rs:92:26
10: script::dom::bindings::principals::ServoJSPrincipals::origin
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/bindings/principals.rs:42:9
11: script::dom::bindings::principals::subsumes
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/bindings/principals.rs:136:22
12: _ZN2jsL30SavedFrameSubsumedByPrincipalsEP9JSContextP12JSPrincipalsN2JS6HandleIPNS_10SavedFrameEEE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/SavedStacks.cpp:617:10
_ZN2jsL20GetFirstMatchedFrameIFbP9JSContextP12JSPrincipalsN2JS6HandleIPNS_10SavedFrameEEEEEES8_S2_S4_RT_S9_NS5_20SavedFrameSelfHostedERb
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/SavedStacks.cpp:636:9
_ZN2jsL21GetFirstSubsumedFrameEP9JSContextP12JSPrincipalsN2JS6HandleIPNS_10SavedFrameEEENS4_20SavedFrameSelfHostedERb
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/SavedStacks.cpp:660:10
13: _ZN2js16UnwrapSavedFrameEP9JSContextP12JSPrincipalsN2JS6HandleIP8JSObjectEENS4_20SavedFrameSelfHostedERb
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/SavedStacks.cpp:744:10
14: _ZN2JS16BuildStackStringEP9JSContextP12JSPrincipalsNS_6HandleIP8JSObjectEENS_13MutableHandleIP8JSStringEEmN2js11StackFormatE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/SavedStacks.cpp:1041:13
15: mozjs::rust::CapturedJSStack::as_string
at /Users/navgattu/.cargo/git/checkouts/rust-mozjs-8611526964119dd6/09edacd/src/rust.rs:1377:17
16: script::dom::webglrenderingcontext::capture_webgl_backtrace::{{closure}}
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:1939:46
17: core::option::Option<T>::and_then
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/core/src/option.rs:1043:24
18: script::dom::webglrenderingcontext::capture_webgl_backtrace
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:1939:27
19: script::dom::webglrenderingcontext::WebGLRenderingContext::send_command
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:397:28
20: script::dom::webglrenderingcontext::WebGLRenderingContext::get_gl_extensions
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:913:9
21: <script::dom::webglrenderingcontext::WebGLRenderingContext as script::dom::bindings::codegen::Bindings::WebGLRenderingContextBinding::WebGLRenderingContextBinding::WebGLRenderingContextMethods>::GetSupportedExtensions::{{closure}}
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:2330:27
22: script::dom::webgl_extensions::extensions::WebGLExtensions::init_once
23: <script::dom::webglrenderingcontext::WebGLRenderingContext as script::dom::bindings::codegen::Bindings::WebGLRenderingContextBinding::WebGLRenderingContextBinding::WebGLRenderingContextMethods>::GetSupportedExtensions
at /Users/navgattu/Documents/dev-git/servo/components/script/dom/webglrenderingcontext.rs:2329:9
24: script::dom::bindings::codegen::Bindings::WebGLRenderingContextBinding::WebGLRenderingContextBinding::getSupportedExtensions::{{closure}}::{{closure}}
at /Users/navgattu/Documents/dev-git/servo/target/debug/build/script-80d43fa6e481c605/out/Bindings/WebGLRenderingContextBinding.rs:1095:46
25: script::dom::bindings::codegen::Bindings::WebGLRenderingContextBinding::WebGLRenderingContextBinding::getSupportedExtensions::{{closure}}
at /Users/navgattu/Documents/dev-git/servo/target/debug/build/script-80d43fa6e481c605/out/Bindings/WebGLRenderingContextBinding.rs:1090:33
26: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/core/src/ops/function.rs:280:13
27: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/core/src/panic/unwind_safe.rs:271:9
28: std::panicking::try::do_call
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/std/src/panicking.rs:403:40
29: <unknown>
at /Users/navgattu/.cargo/git/checkouts/rust-mozjs-8611526964119dd6/09edacd/src/glue.rs:299:6
30: std::panicking::try
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/std/src/panicking.rs:367:19
31: std::panic::catch_unwind
at /rustc/0fa3190394475a84360b34e074e719d519bc40f1/library/std/src/panic.rs:129:14
32: mozjs::panic::wrap_panic
at /Users/navgattu/.cargo/git/checkouts/rust-mozjs-8611526964119dd6/09edacd/src/panic.rs:22:11
33: script::dom::bindings::codegen::Bindings::WebGLRenderingContextBinding::WebGLRenderingContextBinding::getSupportedExtensions
at /Users/navgattu/Documents/dev-git/servo/target/debug/build/script-80d43fa6e481c605/out/Bindings/WebGLRenderingContextBinding.rs:1090:5
34: CallJitMethodOp
at /Users/navgattu/.cargo/git/checkouts/rust-mozjs-8611526964119dd6/09edacd/src/jsglue.cpp:663:12
35: script::dom::bindings::utils::generic_call
36: script::dom::bindings::utils::generic_method
37: _Z12CallJSNativeP9JSContextPFbS0_jPN2JS5ValueEEN2js10CallReasonERKNS1_8CallArgsE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:435:13
_ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:520:12
38: _ZN2js13CallFromStackEP9JSContextRKN2JS8CallArgsE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:584:10
_ZL9InterpretP9JSContextRN2js8RunStateE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:3244:16
39: _ZN2js9RunScriptEP9JSContextRNS_8RunStateE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:405:13
40: _ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:552:13
41: _ZN2js4CallEP9JSContextN2JS6HandleINS2_5ValueEEES5_RKNS_13AnyInvokeArgsENS2_13MutableHandleIS4_EENS_10CallReasonE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:597:8
42: _ZN2js9fun_applyEP9JSContextjPN2JS5ValueE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/JSFunction.cpp:1166:10
43: _Z12CallJSNativeP9JSContextPFbS0_jPN2JS5ValueEEN2js10CallReasonERKNS1_8CallArgsE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:435:13
_ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/vm/Interpreter.cpp:520:12
44: _ZN2js3jit14DoCallFallbackEP9JSContextPNS0_13BaselineFrameEPNS0_15ICCall_FallbackEjPN2JS5ValueENS7_13MutableHandleIS8_EE
at /Users/navgattu/Documents/dev-git/mozjs/mozjs/js/src/jit/BaselineIC.cpp:1841:10
```
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
