HTMLAnchorElement throws with malformed URLs

[Soxasora]

We use LinkeDOM with Lexical to export HTML from an EditorState on the backend.
The PR #204 introduced decodeURI on get href() and get download() to fix double encoding of already encoded characters but this causes every malformed URL to throw URIError.

For example, a LinkNode in Lexical can be anything, can also have % as URL. When it comes to converting the LinkNode to an HTMLAnchorElement via LinkeDOM, decodeURI throws and the whole HTML generation fails.

It's not a real problem, I can sanitize these URLs myself, but I wanted to report this anyway. Thanks a lot for everything, LinkeDOM is really fast!

Logs

URIError: URI malformed
at decodeURI (<anonymous>)
at set href (/var/app/current/node_modules/linkedom/cjs/html/anchor-element.js:19:55)
at y.updateLinkDOM (file:///var/app/current/node_modules/@lexical/link/LexicalLink.prod.mjs:9:1231)
at y.createDOM (file:///var/app/current/node_modules/@lexical/link/LexicalLink.prod.mjs:9:1125)
at y.exportDOM (file:///var/app/current/node_modules/lexical/Lexical.prod.mjs:9:32114)
at y.exportDOM (file:///var/app/current/node_modules/lexical/Lexical.prod.mjs:9:88429)
at x (file:///var/app/current/node_modules/@lexical/html/LexicalHtml.prod.mjs:9:1403)
at x (file:///var/app/current/node_modules/@lexical/html/LexicalHtml.prod.mjs:9:1543)
at x (file:///var/app/current/node_modules/@lexical/html/LexicalHtml.prod.mjs:9:1543)
at g (file:///var/app/current/node_modules/@lexical/html/LexicalHtml.prod.mjs:9:1128)

[WebReflection]

would the standard browser throw in there too? 🤔

[Soxasora]

I mean decodeURI will always throw when it finds partial encoding (% is reserved).
If decodeURI throws then I suppose we can safely fallback to encodeURI.

[WebReflection]

if I put try/catches around everything this will become the new mantra:

LinkeDOM is really fast slow!

as you said you fixed it already, could we just pretend we know how to encode a URI before trashing its content within an attribute? what's next? " allowed as part of the URL or > and others? Just curious how do you see this working later on ...

[Soxasora]

what's next? " allowed as part of the URL or > and others? Just curious how do you see this working later on ...

No, I think we're making the same point. You're right that it's not the job of a DOM library to know the right canonical form of every URI and correct them.

The try/catch wasn't a suggestion, I was pointing out that it's a consequence of doing encodeURI(decodeURI):

• What's the point of encodeURI if by using decodeURI we're expecting an encoded URI anyway?
• Do we lose anything by not doing this decode -> encode step?

edit: probably the reason to do this was to parse the href? In that case was encode(decode) the best solution?
I appreciate your library and I wasn't trashing it or even wanted to argue this, just pointing out something that I didn't expect to find.

[WebReflection]

I think decodeURI has been there for a while while href attribute got recently introduced https://github.com/WebReflection/linkedom/pull/302/files#diff-142c7c36a180e9a7c389dd9301b1d2bd7e8850bee423858bac1371a0033e0cc3R18 ... IIRC getting the attribute would give you different results if you use getAttribute('href') VS .href so that "circus" was there to preserve the dance/difference