import(`data:application/javascript,...')
Reported by
andrea.g...@gmail.com,
Jun 19 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15 Steps to reproduce the problem: 1. visit this codepen https://codepen.io/WebReflection/pen/BVYWmQ?editors=0010 2. see nothing 3. realize if you change application/javascript into text/javascript it works What is the expected behavior? the import(...) accepts inline data URIs, including `text/javascript`, so it should accept the non deprecated / jurassic version of the JS mime too, which is, accordingly to standards, application/javascript. What went wrong? import(...) is half broken. Did this work before? N/A Chrome version: 67.0.3396.87 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.13.5 Flash Version:
,
Jun 20 2018
Able to reproduce the issue on chrome reported version# 67.0.3396.87 using Ubuntu 14.04, Mac 10.12.6 and Windows-10 with steps mentioned below: 1) Launched chrome reported version and navigated to URL: https://codepen.io/WebReflection/pen/BVYWmQ?editors=0010 2) Seen nothing, replaced application/javascript into text/javascript and observations are as follows: From M-60 to M-62, on replacing application/javascript into text/javascript, didn't observed any output From M-63 to M-69, on replacing application/javascript into text/javascript, observed output as "It Works 1 & It Works 2" As we are seeing different behaviour from M-60 to M-69, hence considering this as Untriaged and requesting someone from Blink team have a look at this issue. Thanks!
,
Jun 20 2018
,
Jun 28 2018
Satyha, can you please evaluate?
,
Jul 2
V8 just passes the specifier string to Blink and Blink does the parsing. Assigning to Kouhei to take a look at the Blink parts.
,
Oct 17
It looks like the issue here is that we're expecting an URL-encoded payload for the application/javascript mimetype, which is causing whitespace to be discarded and thus a parse error. This can be observed by entering the following into the URL bar:
`data:application/javascript,function noop() {}`
and observing that the displayed string is `functionnoop(){}`.
Changing `module_script_loader_test.cc` to use `application/javascript` URLs confirms the failure.
I'll take a look at what's being special cased for text/javascript here, and see if we can apply this to application/javascript as well.
,
Oct 17
So it seems like we allow whitespace in text/* and XML input to mimick Mozilla's semantics in `net/base/data_url.cc` (https://cs.chromium.org/chromium/src/net/base/data_url.cc?l=92&rcl=bb833a07a0e8d1ca8222c697d55867ca301eb2a6). This includes text/javascript. The question is, should we extend these semantics to _all_ JavaScript payloads? RFC2396 suggests that whitespace should be ignored for all data URLs. That being said, an equivalency argument can be made for `text/javascript` being widely regarded as synonymous with `application/javascript`, and thus perhaps we should treat it the same universally. FWIW, Firefox does not preserve whitespace in this case either. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Jun 20 2018