Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elemental2 wrapper for DOMParser #157

Open
jiakuan opened this issue Mar 14, 2023 · 8 comments
Open

Elemental2 wrapper for DOMParser #157

jiakuan opened this issue Mar 14, 2023 · 8 comments

Comments

@jiakuan
Copy link

jiakuan commented Mar 14, 2023

Can't find DOMParser from the current elemental2 library.
https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

Shall we support it as well?

@gkdn
Copy link
Member

gkdn commented Mar 14, 2023

@jDramaix This is defined in https://github.com/google/closure-compiler/blob/master/externs/browser/gecko_xml.js though I don't see us using any extern named gecko (though this one doesn't seem Mozilla specific)

@niloc132
Copy link
Contributor

When I asked the closure-compiler maintainers some years ago about the different browser-named extern files, they indicated that this was often the original source of that type, and that it wouldn't be beneficial to migrate the externs out of that file and into something common now that the type is standardized.

@jDramaix
Copy link
Member

jDramaix commented Mar 15, 2023

Yes we do not use any specific browser extern files. If the api has been standardized we need to move the api in another extern file (w3c_xml.js in this case). Contribution is welcome :)

@niloc132
Copy link
Contributor

It looks like my memory is faulty or policy has changed: I can't find the specific conversation where gwt community members were asked to not bulk migrate standardized entries, but google/closure-compiler#2478 is one such conversation.

The entire gecko_dom.js is standardized now (with the exception of the serializer method serializeToStream, which is no longer supported by any browser that I can see), but as it is only a few members, so I'll see about moving it.

@jDramaix
Copy link
Member

The problem is that DOMParser.parseFromString() is accepting a TrustedHTML and this is not supported in Elemental2 yet.

@zbynek
Copy link
Contributor

zbynek commented Feb 27, 2024

@jDramaix elemental also includes w3c_range that uses TrustedHTML, is that also a problem? https://github.com/google/closure-compiler/blob/46131b1844fb070316a98c5b4c047ee3d786553e/externs/browser/w3c_range.js#L250

"//third_party:w3c_range.js",

@jDramaix
Copy link
Member

jDramaix commented Feb 28, 2024

The definition of the types are there but there is no J2CL/GWT way to instantiate them (I don't even know a standard way to instantiate them on JS). Also, the version of DOMParser.parseFromString() taking a String is considered as unsafe and the Elemental2 build will fail internally at Google. So we would end up generating Java code only targeting the signature using TrustedHTML. It' not a working solution as it would not be usable by most users.

@zbynek
Copy link
Contributor

zbynek commented Feb 28, 2024

I don't even know a standard way to instantiate them on JS)

So is this issue blocked by FireFox+Safari support for trusted types? (mozilla/standards-positions#20, https://webkit.org/standards-positions/ doesn't even mention it).
Elemental already contains the code needed for instantiating trusted HTML in Chromium

TrustedTypePolicyOptions tpo = TrustedTypePolicyOptions.create();
tpo.setCreateHTML((str, ignore) -> str);
DomGlobal.trustedTypes.createPolicy("unsafe", tpo).createHTML("<img>");

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants