New issue
Advanced search Search tips

Issue 831313 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

import.meta.url does not contain fragment of url

Reported by bradley....@gmail.com, Apr 10 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. import './foo.mjs#bar'
2. try to log 'import.meta.url'

What is the expected behavior?
to include '#bar'

What went wrong?
it doesn't have '#bar'

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 65.0.3325.181  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
Cc: hirosh...@chromium.org kouhei@chromium.org
Components: -Blink>JavaScript Blink>Loader
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Status: Available (was: Unconfirmed)
hiroshige@, can you ptal?
Cc: domenic@chromium.org
Components: Blink>HTML>Script
According to HTML spec, import.meta.url is response's URL
(Set in Step 10 of https://html.spec.whatwg.org/#fetch-a-single-module-script which will be referenced in https://html.spec.whatwg.org/#hostgetimportmetaproperties).

According to a WPT test
https://codesearch.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/fetch/api/basic/response-url.js
Fragments in the request URLs are dropped in response URLs, on Chrome/Edge/Firefox/Safari.
https://wpt.fyi/fetch/api/basic/response-url.html
(I'm not sure where this is spec'ed, but anyway this is the current behavior consistent across browsers)

Therefore, this is working as intended.
If #bar is needed in import.meta.url, then I think this is a spec issue.
+domenic@ for HTML spec.

What is your use case for the fragment in the import.meta.url?

> Does this work in other browsers? Yes
Which browsers did you test? Safari?

Interesting, this appears to be a spec oversight. Per https://fetch.spec.whatwg.org/#response-url the intent is never to expose fragments here. But it appears you need to explicitly censor them in spec text, e.g. like https://fetch.spec.whatwg.org/#dom-response-url does. And the HTML spec does not remember to censor while serializing, so it's easy to see how an interop problem would have happened here. I will file a bug.
I tested in Safari 11.1

Use case is allowing specialization of module records without network loading.

Related: https://github.com/nodejs/modules/issues/60 https://github.com/WICG/webpackage/issues/172
Screen Shot 2018-04-10 at 4.02.33 PM.png
109 KB View Download
@domenic I would request that we allow exposing this in `import.meta.url`, but I think you are intending to not given the above comment. Is there a reason to censor `import.meta.url`'s fragments?
Cc: domfarolino@gmail.com

Sign in to add a comment