Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[dart:html] Update Trusted Types APIs
Closes b/195948578 Modifies Trusted Types APIs to be compliant with the spec in https://w3c.github.io/webappsec-trusted-types/dist/spec/. Change-Id: I65d52ace12342ce777ab596a9dd2e9a3f74b2f05 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212270 Commit-Queue: Srujan Gaddam <srujzs@google.com> Reviewed-by: Riley Porter <rileyporter@google.com>
- Loading branch information
Showing
4 changed files
with
357 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@srujzs There have been many reasonable requests to update the Dart SDK to support various web apis over the years. All seemingly get rejected with, "it's very difficult to update any web apis, we're looking for a better way to do that, stay tuned", but yet, this one gets in. Why is that?
bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi mnordine,
This change is intended to support security conformance of internal packages, making it a higher priority for us, which is why this one met the bar.
As for work in updating web APIs, our interop work is currently focused on enabling static JS interop on Native types, enabling users to sidestep many of the issues with writing their own interfaces for types reserved by dart:html. We also had some recent work in enabling the move of dart:html types to static extensions, which should hopefully enable users to write their own APIs without conflicts as well. There's a bit of logistics left to determine how to properly migrate these types. Thank you for your patience.
bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@srujzs thank you for taking the time to reply, I figured it was security-related.
As for "enabling static JS interop on Native types", any way you could give an example, as I'm not sure exactly what that entails?
bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be useful to drop #35084 for context. The goal we want to achieve with interop is to move things to something more statically typed. Eventually, extension types/views will help us get there, but that's a WIP, so we're setting up interop such that it becomes a simpler migration to extension types.
To address your question: right now, if we try to use
package:js
onNative
types, we get a static error indicating that the type is reserved. This is because the type hierarchy is set up such thatNative
types are siblings ofJavaScriptObject
(which contains allpackage:js
types). This hierarchy is natural, because we need to have a singular type at runtime for dispatch. However, this presents the issue that we can't usepackage:js
types onNative
types (because it would get intercepted as theNative
type at runtime even if we tried).Since this restriction is entirely due to dynamic dispatch, we can be a bit smarter and allow
package:js
to be used as long as the@JS
type is "static". So, something like the following:would allow you to use
package:js
interfaces forNative
types. If for whatever reason,navigator
did not exist on thedart:html
Window
or it was broken, this allows you to use the@JS
type you wrote instead for that object. Right now, writing extension methods directly on theNative
type is a bit unideal, because it may conflict with the definitions within theNative
type, so this should make it easier to use interop withNative
types.bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what problem this solves if there is no
Navigator
type to begin with? Do we then have to do something like:bda31c2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, if there was no conflict to begin with, then you could use interop as usual. The problem comes up when you want to write your own interfaces on types that are reserved by
dart:html
. The APIs within those types may likely be outdated, incorrect, or broken. Currently, you'd either have to use extensions on those Native types (which has its own conflicts) or usejs_util
to workaround it, removing the benefit ofpackage:js
.The code sample you gave would work fine if none of those types existed in
dart:html
(well, maybe not the Future one, since that requires a conversion, but extensions would now allow you to do that conversion). If those types did exist, then with the new changes, you'd just move those members to static extensions.The critical thing here is we want users to be able to use interop to work around the shortcomings of
dart:html
in a robust future-proof way that aligns with what we expect a future interop-based web library package to look like.