-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should HostImportModuleDynamically provide a referencing script? #363
Comments
WebKit's implementation, if I read it right -- and I'm only about 60% sure -- does seem to pass the caller's source origin to |
From previous discussions, my intuition here is to think about |
@caridy please see #364 (comment) if we do |
@leobalter I have updated my example, but that's not the important part, I just forgot to add the second argument. |
The null referencing script for dynamic import in html occurs in such cases: <button onclick="import(`my-module.js`)">click me</button>
I am confused by this point, can you clarify? There are other ways to detect if you are in a shadow realm, for example -- missing APIs. From my perspective, the main outcome of this choice would be to make it harder to use from the calling realm if you are importing nested siblings. The referencing script is only used to propagate the script fetch options and the directory we are "currently" in so that the import specifier can be shorter. Script fetch options aren't exposed beyond fetch behavior, and what this would effectively do is allow a shadow realm to escape a script element's referrer policy, etc. Is that the goal? One might say that this is "detectable" but only at the point of fetch, not as the script is executing. |
If I recall correctly, what's at stake here is just how relative paths in the module specifier are resolved. I think at some point we decided to be conservative here and force document-relative paths because importValue is a method rather than a piece of syntax, where syntax can logically close over the enclosing source location. On the other hand, it seems convenient to go the other way and use the context of the currently executing script. So I don't have a strong opinion here. |
This is a very old issue, and the spec is not using
@nicolo-ribaudo probably have more details. I'm closing the issue, as it seems that when invoking |
Implementing ShadowRealms in Gecko seems to indicate to me that the call to HostImportModuleDynamically should actually not provide null as the referencingScriptOrModule, but actually the executing script that invokes importValue (experimentally, this works in Gecko more like how Shadow Realms module resolution seems like it ought to).
In Gecko, the referencingScriptOrModule is used to determine the imported script's base URL (functionally, expanding
./foo.js
to the actual URL to be loaded); if it's left out, we currently default to the base URL of the document, which can be incorrect.This could just be a matter of requiring compatibility change on the HTML side; The HTML spec says that if you don't provide referencingScriptOrModule, the base URL will be the base URL of the 'current settings object'. As I understand it, that probably should be the settings object of the ShadowRealm's realm; however, that poses a problem because it's never defined anywhere what that settings object ought to contain.
It seems like
import
andimportValue
sharing the same referencingScriptOrModule would make sense...The text was updated successfully, but these errors were encountered: