https://bugs.webkit.org/show_bug.cgi?id=220688
Bug ID: 220688
Summary: Preload Scanner Incorrectly Fetches Scripts With
Malformed or Invalid Type Attributes
Product: WebKit
Version: Safari 14
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Page Loading
Assignee: webkit-unassigned at lists.webkit.org
Reporter: csswizardry at gmail.com
CC: beidson at apple.com
Unfortunately, the HTML spec is a little loose/vague/contradictory/not helpful to us here, but, if we take this excerpt:
> Setting the [type] attribute to any other value [than Omitting the attribute, setting it to the empty string, or setting it to a JavaScript MIME type essence match] means that the script is a data block, which is not processed.
— https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type
This tells us that any script element with a non-matching, malformed, or otherwise illegal type attribute must be skipped by the parser. WebKit’s primary parser does exactly as we’d expect. Take the following example:
```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, minimum-scale=1.0" />
<title>Hello, World!</title>
</head>
<body>
<h1>Test</h1>
<script type="text/javascript">console.log('Valid type attribute')</script>
<script>console.log('Absent type attribute')</script>
<script type="text/_javascript">console.log('Invalid type attribute')</script>
<script type="foo" src="https://slowfil.es/file?type=js"></script>
</body>
</html>
```
The third and final `console.log` will not fire, nor will the file download.
However, the problem is with the preload scanner, which WILL begin requesting files from scripts with malformed type attributes.
EXAMPLE
=======
I can’t provide a useful, live URL as it’s subject to change, but please compare these waterfall charts: https://www.webpagetest.org/video/compare.php?tests=210117_Di8Q_83799f2f5ad00709f8049ce2d5ba8893-l:Chrome,210117_DiYE_07dc92513dc95cd9fbbbad2d4cda5009-l:Firefox,210117_DiT8_6a471556eeec59693b66ea29b1f07d73-l:Safari&thumbSize=200&ival=100&end=visual
This page uses Cloudflare’s Rocket Loader which hard-defers JS by malforming script tags’ type attributes directly in the HTML at the edge, e.g.:
```
<script defer src="/_ui/build/manifest.bundle.js?v=khnYwIsQ" type="6a915e949552efda43f84cd1-text/javascript"></script>
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
```
This means that the HTML payloads’ script tags are all effectively hidden from the browser. Then, later, Rocket Loader kicks in on the client and turns the type attributes back to something valid, causing scripts to run and/or download. In the Chrome and Firefox waterfalls, you’ll see this all working as expected—no *bundle.js downloads until Rocket Loader has run. By comparison, the Safari waterfall shows all of these bundles downloading ahead of time. These downloads are all coming out of the preload scanner.
I’m in a discussion about what the *actual* behaviour should be as the spec skips finer detail, but there is definitely inconsistency between Safari’s primary- and preload-scanners where this is concerned. It would be nice if there was parity here.
I worry that was too wordy to be very clear—let me know if I can clarify anything.
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210117/25286870/attachment.htm>