When `<o` characters in Playground HTML input causes entire JavaScript input to show up in HTML preview

[scornork]

What information was incorrect, unhelpful, or incomplete?

1. Using the characters "<o" in the Playground's HTML input area, causes whatever is in the JavaScript input area to show up in the HTML preview.

2. Behavior persists so long as the tag (intended to use <output> when I discovered this by accident) remains incomplete even if there are inputs that precede or succeed it.

3. Can't tell if this is the result of a mishandling of some string interpolation, some quirk with the playground or if its an inherent problem with the HTML tag itself

4. Not too sure if its isolated only to certain devices but am experiencing it on a Pixel 10 Pro Fold and a 2020 13" MacBook Pro.

5. Also not sure if this is tantamount to using .innerText which might not be so worrying than of its an equivalent of innerHTML, for e.g., hence this issue...

6. And a live example you can use as a reference if it occurs at all,

otherwise please refer to the screenshots attached for more details.

What did you expect to see?

Nothing. Incomplete HTML tags either show up as they are typed or as nothing at all and nor expose another element's content.

Do you have any supporting links, references, or citations?

As provided:

1. live example
2. 
3. 

Do you have anything more you want to share?

No response

[scornork]

2. Behavior persists so long as the tag (intended to use <output> when I discovered this by accident) remains incomplete even if there are inputs that precede or succeed it. ❌

• I stand corrected. The behaviour ceases the moment it is enclosed with valid tags; for e.g. <strong><o</strong> is wrapping it.

PS: it seems like the entire playground is rendered at one go based on what goes into the string interpolation here, especially the runner preview. I can see why it should output all at one go but it maybe this is also why syntax errors in the HTML is missed and the render ends up exposing the JavaScript codes as a result. Subjecting the render to some conditional control flow that first checks the content of storage variable holding each input areas codes is not empty and then checks its syntax before deciding to output whatever is currently in the playground or to throw an exception. Feels clunky but just my two cents worth!

[globau]

What's happening here is the javascript is concatenated after the html, resulting in:

annn <o jwj
<script type="">
   console.log("this is inserted into the DOM when the \"<\" + \"o\" characters are in the HTML textarea");;
</script>

or, formatted to match how its parsed:

annn <o jwj <script type="">
   console.log("this is inserted into the DOM when the \"<\" + \"o\" characters are in the HTML textarea");;
</script>

the opening script element is parsed as part of the o element, resulting in console.log being treated as in-page content.

We'll have discussions about how this could be addressed.

[scornork]

Thanks for sharing. Great to know the cause has been isolated.

Agree that escaping might be the way although because of validation overheads, I had naively wanted to suggest storing the charCode or codePoints in a Uint8Array or Uint16Array buffer and use generators + usual timeouts to lazily evaluate and interpolate the strings.

Figured midway through that implementation would be just as tedious as my attempt in articulating the whole approach so... 😅 nah.

[globau]

Another option is to detect when there are unclosed tags and show an unobtrusive warning to indicate that the rendering could be invalid until the html is closer to valid.

[scornork]

That's actually a really elegant way of dealing with the deferment of the render given how it is now justified with a corrective action for the user to take.

Which takes the pressure to address any overhead issues almost completely since the ball is now in user's court.

Painfully simple and incisively effective and yet it didn't even cross my mind 🥲

Thank you!

[globau]

Given the complexity around detecting malformed content, as a stop-gap we'll perform a quick post-rendering check to ensure the script element is present and in the expected location in the playground's content iframe.

[scornork]

Sorry, just a really naive thought - it seems like this is only an issue under two condition:

1. A whitespace must delineate the two character groups, and
2. This likely as to be the (top?)-left most character in order for it to start affecting the everthing after it.

If true, would it help optimise the effort by
a. Splitting the entire template literal by whitespaces (immediately negates the rendering issue)
b. Either focus validations at the at the start of sentences and paragraphs, or filter all matches but pull their neighbouring token by +1 or -1 index into a smaller subset to review.
c. Do whatever's needed to rectfiy or just throw an error

Its still a convoluted process no doubt, but it might just be tad lighter to achieve.

Just my two cents' worth as I could be completely wrong in some assumptions I made.