Commit-Queue | +0 |
Hi Joey, please take a look. I adopted the naming suggestions from our email discussion.
I'm sorry for how very long this CL is, but I couldn't really come up with a meaningful split. Also, you own nearly all of this code. :)
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
12 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: third_party/blink/renderer/core/css/style_engine_test.cc
Insertions: 13, Deletions: 0.
The diff is too large to show. Please review the diff.
```
[Trusted Types] Implement Element.inner/outerHTML without StringContext.
The [StringContext=] extendend IDL attribute is a Chrome-specific
mechanism to implement Trusted Types. TT is currently being integrated
into the HTML spec, and the spec editors decided against the
StringContext IDL attribute, and instead specify Trusted Types checks
"manually" in the spec. In some instances -- but not here -- the
difference between the IDL-based and the "manual" TT checks is observable, due to the when the TT check is being made.
This CL re-implements the Trusted Types check of the following properties, without StringContext:
- Element, innerHTML + outerHTML
- Shadow root, innerHTML
These methods are very popular in testing code, which unfortunately
makes this CL quite long.
This CL should not introduce any behavioural changes. If the updated
HTML specs introduces changes relative to Chrome's current behaviour,
we will implement those semantic changes in a separate CL, behind a
flag. Here, we only change the mechanism.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
String compliant_html = TrustedTypesCheckForHTML(
On a quick check this seems to be quite a lot more expensive then the older version? How do we expect this to roughly yield in the same performance?
Are we already doing more checks or are they only enabled later on?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
String compliant_html = TrustedTypesCheckForHTML(
On a quick check this seems to be quite a lot more expensive then the older version? How do we expect this to roughly yield in the same performance?
Are we already doing more checks or are they only enabled later on?
This should be the exact same check that was run before. It only moves the check to a different location. I'm not expecting performance or semantic differences.
On the version before this change, f2047d204c54f8571c4bc5d0031bb06d37468ae1:
- Bindings:
- https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_element.cc;l=621-651;drc=f2047d204c54f8571c4bc5d0031bb06d37468ae1
- This calls
NativeValueTraits<IDLStringLegacyNullToEmptyStringStringContextTrustedHTML>::NativeValue (line 640). Note the type.
- https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/idl_types.h;l=182-184 defines IDLStringLegacyNullToEmptyStringStringContextTrustedHTML as IDLStringStringContextTrustedHTMLBase<
bindings::IDLStringConvMode::kLegacyNullToEmptyString>
- NativeValues<IDLStringStringContextTrustedHTMLBase<.>> is defined here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/native_value_traits_impl.h;l=486-508
- In line 505, this runs the exact same check that the new version runs.
- After this change, the bindings look mostly the same, but now with a different type:
- https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_element.cc;l=630-657
- This NativeValueTraits should not run the TT check.
- Instead, the exact same TT check is now run as the first thing of Element::setInnerHTML.
------
Generally, none of the current or future changes should do *more* checks.
String compliant_html = TrustedTypesCheckForHTML(
Daniel VogelheimOn a quick check this seems to be quite a lot more expensive then the older version? How do we expect this to roughly yield in the same performance?
Are we already doing more checks or are they only enabled later on?
This should be the exact same check that was run before. It only moves the check to a different location. I'm not expecting performance or semantic differences.
On the version before this change, f2047d204c54f8571c4bc5d0031bb06d37468ae1:
- Bindings:
- https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_element.cc;l=621-651;drc=f2047d204c54f8571c4bc5d0031bb06d37468ae1
- This calls
NativeValueTraits<IDLStringLegacyNullToEmptyStringStringContextTrustedHTML>::NativeValue (line 640). Note the type.
- https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/idl_types.h;l=182-184 defines IDLStringLegacyNullToEmptyStringStringContextTrustedHTML as IDLStringStringContextTrustedHTMLBase<
bindings::IDLStringConvMode::kLegacyNullToEmptyString>
- NativeValues<IDLStringStringContextTrustedHTMLBase<.>> is defined here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/native_value_traits_impl.h;l=486-508
- In line 505, this runs the exact same check that the new version runs.
- After this change, the bindings look mostly the same, but now with a different type:
- https://source.chromium.org/chromium/chromium/src/+/main:out/linux-Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_element.cc;l=630-657
- This NativeValueTraits should not run the TT check.
- Instead, the exact same TT check is now run as the first thing of Element::setInnerHTML.------
Generally, none of the current or future changes should do *more* checks.
Thanks a lot for all the pointers.
[CEReactions, RuntimeCallStatsCounter=ElementInnerHTML, RaisesException=Setter] attribute (TrustedHTML or [LegacyNullToEmptyString] DOMString) innerHTML;
For what it's worth, another alternative here (which I think may have been preferable despite [the documentation](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/IDLExtendedAttributes.md) saying otherwise) would have been to:
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[CEReactions, RuntimeCallStatsCounter=ElementInnerHTML, RaisesException=Setter] attribute (TrustedHTML or [LegacyNullToEmptyString] DOMString) innerHTML;
For what it's worth, another alternative here (which I think may have been preferable despite [the documentation](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/IDLExtendedAttributes.md) saying otherwise) would have been to:
- use `ImplementedAs=innerHTMLForBinding` and then implement the methods `innerHTMLForBinding` and `setInnerHTMLForBinding` as the binding-exposed methods
- leave the usable-from C++ methods with the existing names rather than renaming them to be `GetInnerHTMLString` and `SetInnerHTMLWithoutTrustedTypes`
That was one option that's been considered. (E.g. patch set #6 of the first patch in this series, https://chromium-review.googlesource.com/c/chromium/src/+/6593311/6)
I'd have been happy with that naming, too, but in the end the code reviewers should have last word. The xxWithoutTrustedTypes variant came out as the preferred one. I'll copy you on the discussion thread for additional context. I'll gladly use whichever naming scheme finds consensus among reviewers. If it changes, I'll send additional CLs to rename it.
void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
This broke libfuzzer build?
```
../../third_party/blink/renderer/modules/canvas/canvas_fuzzer.cc:53:39: error: too few arguments to function call, expected 2, have 1
52 | GetDocument().documentElement()->setInnerHTML(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
53 | String::FromUTF8(body_content));
| ^
../../third_party/blink/renderer/core/dom/element.h:1266:8: note: 'setInnerHTML' declared here
1266 | void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1267 | ExceptionState&);
| ~~~~~~~~~~~~~~~
1 error generated.
```
void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
This broke libfuzzer build?
```
../../third_party/blink/renderer/modules/canvas/canvas_fuzzer.cc:53:39: error: too few arguments to function call, expected 2, have 1
52 | GetDocument().documentElement()->setInnerHTML(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
53 | String::FromUTF8(body_content));
| ^
../../third_party/blink/renderer/core/dom/element.h:1266:8: note: 'setInnerHTML' declared here
1266 | void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1267 | ExceptionState&);
| ~~~~~~~~~~~~~~~
1 error generated.
```
My apologies for the breakage. This should (now) use SetInnerHTMLWithoutTrustedTypes instead of setInnerHTML.
I would have noticed & fixed this if this target had been built on any of the bots on the CQ. For my information: Which target should I have built to notice this?
void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
Daniel VogelheimThis broke libfuzzer build?
```
../../third_party/blink/renderer/modules/canvas/canvas_fuzzer.cc:53:39: error: too few arguments to function call, expected 2, have 1
52 | GetDocument().documentElement()->setInnerHTML(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
53 | String::FromUTF8(body_content));
| ^
../../third_party/blink/renderer/core/dom/element.h:1266:8: note: 'setInnerHTML' declared here
1266 | void setInnerHTML(const V8UnionStringLegacyNullToEmptyStringOrTrustedHTML*,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1267 | ExceptionState&);
| ~~~~~~~~~~~~~~~
1 error generated.
```
My apologies for the breakage. This should (now) use SetInnerHTMLWithoutTrustedTypes instead of setInnerHTML.
I would have noticed & fixed this if this target had been built on any of the bots on the CQ. For my information: Which target should I have built to notice this?
Fix in https://chromium-review.googlesource.com/c/chromium/src/+/6703641. I'll send it to you for review.