This change replaces OpenSSL with rustls and also the manually curated
CA certs file with webpki-roots (effectively the same thing, but as a
crate).
Generally speaking the design of the network stack is the same. Changes:
- Code around certificate overrides needed to be refactored to work with
rustls so the various thread-safe list of certificates is refactored
into `CertificateErrorOverrideManager`
- hyper-rustls takes care of setting ALPN protocols for HTTP requests,
so for WebSockets this is moved to the WebSocket code.
- The safe set of cypher suites is chosen, which seem to correspond to
the "Modern" configuration from [1]. This can be adjusted later.
- Instead of passing a string of PEM CA certificates around, an enum is
used that includes parsed Certificates (or the default which reads
them from webpki-roots).
- Code for starting up an SSL server for testing is cleaned up a little,
due to the fact that the certificates need to be overriden explicitly
now. This is due to the fact that the `webpki` crate is more stringent
with self-signed certificates than SSL (CA certificates cannot used as
end-entity certificates). [2]
1. https://wiki.mozilla.org/Security/Server_Side_TLS
2. https://github.com/briansmith/webpki/issues/114Fixes#7888.
Fixes#13749.
Fixes#26835.
Fixes#29291.
* Add `no_trace` option to JSTraceable derive
* NoTrace wrapper
* Port some types to no_trace schematics
* Fixing my unsafe mistakes (not tracing traceables)
* Add docs & safety guards for no_trace
Safety guards (trait shenanigans) guarantees safety usage of `no_trace`
* Port canvas_traits to no_trace
* Port servo_media to no_trace
* Port net_traits to no_trace
* Port style to no_trace
* Port webgpu to no_trace
* Port script_traits to no_trace
* Port canvas_traits, devtools_traits, embedder_traits, profile_traits to no_trace
* unrooted_must_root lint in seperate file
* Add trace_in_no_trace_lint as script_plugin
* Composable types in must_not_have_traceable
* Introduced HashMapTracedValues wrapper
* `HashMap<NoTrace<K>,V>`->`HashMapTracedValues<K,V>`
* Port rest of servo's types to no_trace
* Port html5ever, euclid, mime and http to no_trace
* Port remaining externals to no_trace
* Port webxr and Arc<Mutex<_>>
* Fix spelling in notrace doc
* 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)
This is a step toward upgrading WebRender, which will be upgraded and
patched in the `third_party` directory. This change vendors the current
private branch of WebRender that we use and adds a `patches` directory
which tracks the changes on top of the upstream WebRender commit
described by third_party/webrender/patches/head.
CSS viewport removal
It was removed from the spec and it's disabled everywhere.
This also removes the meta viewport support (which was implemented on top), but that also had a single test and is disabled everywhere, so I'm not too concerned, it can be implemented again if / when needed.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#26349
- [x] There are tests for these changes
This also removes the meta viewport support (which was implemented on top), but that also had a single test and is disabled everywhere, so I'm not too concerned, it can be implemented again if / when needed.
This directory now contains third_party software that is vendored into
the Servo source tree. The idea is that it would eventually hold
webrender and other crates from mozilla-central as well with a standard
patch management approach for each.
Remove the DOMToTexture feature
This relies on WebRender's frame output API, `set_output_image_handler`,
which has been removed from the latest upstream [1]. It's sad to remove
this feature, which was probably a lot of work to implement, but it
seems difficult to patch WebRender to restore this functionality.
Fixes#29936.
1. https://hg.mozilla.org/mozilla-central/rev/361521e3c52324809553c555fb066d50f023d9bf
<!-- 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#29936.
- [x] These changes do not require tests because they remove functionality.
<!-- 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. -->
This relies on WebRender's frame output API, `set_output_image_handler`,
which has been removed from the latest upstream [1]. It's sad to remove
this feature, which was probably a lot of work to implement, but it
seems difficult to patch WebRender to restore this functionality.
Fixes#29936.
1. https://hg.mozilla.org/mozilla-central/rev/361521e3c52324809553c555fb066d50f023d9bf
Support extending DOM classes in JS
Adds support for determining the correct prototype as part of a `new` call for non-HTML constructors. Support for HTML constructors [was added](https://github.com/servo/servo/blob/master/components/script/dom/bindings/htmlconstructor.rs#L116) as part of the custom element work, but that wasn't enough for extending other DOM objects like `EventTarget`.
This work is based on Gecko's code in https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/dom/bindings/BindingUtils.cpp#3667, and is split into two parts:
1) the actualy new implementation (demonstrating that extending `EventTarget` works as expected)
2) plumbing the new prototype through all of the rest of the DOM object construction code.
This ends up being more complex than the way it's done in Gecko because they have lazy DOM reflectors, so their native DOM objects can be constructed without any knowledge of a JS prototype. Servo's reflectors are eager, however, so we need to propagate prototype information into individual constructors. As a result, this was a tedious set of changes to make.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#29770
- [x] There are tests for these changes
Backport several style changes from Gecko
<!-- 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
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [X] 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. -->
