Playground should not be able to generate URLs that exceed the maximum length

[globau]

Via mdn/content#43892

URLs have a maximum length of 8k - it's possible using the playground to generate longer URLs.

We should, at least:

• add validation in the Playground directly that prevents generation of URLs exceeding 8000 encoded characters
• add a Content built-time test to as a backstop

[LeoMcA]

Started to explore a couple of options as fallbacks when the URL does exceed 8k:

• wip(play): minify examples over 8k #1513
• wip(play): use postMessage for examples over 8k #1512

Unfortunately the PR preview doesn't build any pages which have these long examples, so testing needs to be done locally:

1. http://localhost:3000/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/Video_player_styling_basics#result
2. http://localhost:3000/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video#result
3. http://localhost:3000/en-US/docs/Web/CSS/Guides/Colors/Color_mixer
4. http://localhost:3000/en-US/docs/Web/API/CanvasRenderingContext2D/arcTo#constructing_an_arcto_path

Here's the sizes of each in bytes currently, and with the two above approaches:

example	current	minify	postMessage
1	9807	9303	497
2	11034	10186	514
3	8013	7093	461
4	10162	4674	466

minify approach

This uses terser with default options to minify the JavaScript in each example. We could also use similar libraries to do the same to the HTML and CSS - though nothing will really get around the large embedded PNGs in the first two examples.

Unfortunately, this adds quite a bit to bundle size, doubling the size of JS over the wire (146kB to 298kB compressed; 370kB to 880kB uncompressed), though this is loaded async, so only on pages which require it.

We could roll our own regex to strip whitespace, comments etc. but I'd be concerned at our ability to handle every edge case (e.g. whitespace within strings), and isn't really something I think we should maintain.

The advantage of a minimisation approach is it already works with the other things you can do from an example, namely:

• click the Play button and have it appear in the Playground
• right click within the iframe, and open that in a new tab

However, users will see the minified source within the Playground/new tab warning screen, which isn't the nicest. We do have a format button, but this won't handle minification which renames variables, for example.

postMessage approach

This loads a shim example in the iframe, which waits for a message from the parent frame containing the actual example code, and inserts the css into the empty <style> tag, innerHTMLs the HTML, and creates and adds a <script> containing the JS into the page.

The advantage of this is that's it's a minor change, with no external deps (or regexes to maintain) and somewhat mirrors what we do already with CSS interactive examples.

The main disadvantage is that clicking the Play button or opening the iframe contents in a new tab will only load the shim code.

We could fix the Play button by stashing the real contents in localStorage and retrieving it one the Playground tab opens (and we'd possibly want to do the same for the minified examples). There's not really a whole lot we can do with opening the iframe in a new tab: though this isn't really an advertised feature, just a nice side effect.

A more minor disadvantage is that this won't work properly with things like the DOMContentLoaded event: as that will have been and gone by the time the code is inserted into the page. None of these examples seem to rely on APIs like that, however, and the behaviour will be replicated locally when authors are editing examples.

I think there's also a bug in my WIP code around the handling of the hash - it's why the size of the URL varies, despite the shim code being the same (I'm still using the hash from the original example) - I need to trace that through and check if that's a problem.

my conclusion

I'd suggest us going with the postMessage approach for now, and disabling the play button on these large examples. It fixes the most common use of them (interaction on the page), without any large dependencies or possible edge cases, and for all the examples (not just the latter two).

If we want to properly support examples larger than 8k it buys us some time to do that, but as it seems like we don't really want to, it's a minimal way to provide a nicer fallback than a CDN error.