The current implementation would transfer the script string to `mozjs`
without telling `mozjs` that the string is UTF-8 encoded, causing
problems when the script carries Chinese characters. This PR fixes this
by using a correct API `mozjs::jsapi::JS_NewStringCopyUTF8N`. Also
changed `TrustedXxx::data()` to return a `&DOMString` to reduce one
unnecessary cloning when transferring script string to `mozjs`
Testing: Manual testing. Would like to ask for community ideas on
introducing new test covering this
---------
Signed-off-by: minghuaw <michael.wu1107@gmail.com>
This implements LazyDOMString (from now on DOMString) as outlined in
https://github.com/servo/servo/issues/39479.
Constructing from a *mut JSString we keep the in a
RootedTraceableBox<Heap<*mut JSString>> and transform
the string into a rust string if necessary via the `make_rust_string`
method.
Methods used in script are implemented on this string. Currently we
transform the string at all times.
But in the future more efficient implementations are possible.
We implement the safety critical sections in a separate module
DOMStringInner which allows simple constructors, `make_rust_string` and
the `bytes` method.
This method returns the new type `EncodedBytes` which contains the
reference to the underlying string in either format.
Testing: WPT tests still seem to work, so this should test this
functionality.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This is part of the future work of implementing LazyDOMString as
outlined in issue #39479.
We use str() method or direct implementations on DOMString for these
methods. We also change some types.
This is independent of https://github.com/servo/servo/pull/39480
Signed-off-by: Narfinger Narfinger@users.noreply.github.com
Testing: This is essentially just renaming a method and a type and
should not change functionality.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Also bumps mozjs to the latest version that has support for
`GStackVector` which is what this callback uses.
Part of #36258Fixes#38877
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This shows up sometimes in code reviews, so it makes sense that tidy
enforces it. `rustfmt` supports this via comment normalization, but it
does many other things and is still an unstable feature (with bugs).
Testing: There are new tidy tests for this change.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Callers now call `set_attribute` directly, to avoid the trusted types
machinery, as well as skip validation. That's not required by spec as
well.
This implements part of the DOM integration from
https://github.com/whatwg/dom/pull/1268
Part of #36258
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
It implements the new codeForEvalGets callback to retrieve the
value for a trusted script object. Additionally, it implements
the new logic in can-compile-strings to call the policy
factory if required.
Note that parameter and argument checks aren't implemented yet,
as they require updates to binding generation (see TODO in
script_runtime).
Part of #36258
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
This avoids various conversions back and forth between DOMString and
String. By using DOMString consistently, we avoid these
double-conversions. The only caveat are the USVString which are
initially passed into
TrustedScriptURL.
Part of #36258
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
As a follow-up to the recent introduction of `script.src`
as trusted sink, this PR refactors machinery to also
support `TrustedScript`. In doing so, all trusted sinks
in `HTMLScriptElement` are now covered.
Instead of calling the callbacks in `policy.createX`,
we now have a `TrustedType` enum that specifies which callback
to invoke. Unfortunately we still have the `USVString` vs
`DOMString` problem, which is why we need to `.map` twice
to retrieve the backing `String` and avoid two different
types.
Additionally, I saw that `script.text` should have called
the "String replace all" algorithm rather than setting the
child contents. So that's also now fixed.
Part of #36258
Requires servo/html5ever#608
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
Some methods are implemented fully, while others are implemented
partly. With these implementations, there are no observed crashes
when running the trusted-types web-platform-tests.
Most notably, the tests/wpt/tests/trusted-types/idlharness.window.js
is now fully passing.
Part of #36258
Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
