Skip to content
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

Closed
mgaudet opened this issue May 26, 2022 · 7 comments
Closed

Should HostImportModuleDynamically provide a referencing script? #363

mgaudet opened this issue May 26, 2022 · 7 comments
Assignees

Comments

@mgaudet
Copy link

mgaudet commented May 26, 2022

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 and importValue sharing the same referencingScriptOrModule would make sense...

@mgaudet
Copy link
Author

mgaudet commented May 26, 2022

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 importModule, which seems to control how the baseURL is determined as well.

@caridy
Copy link
Collaborator

caridy commented May 26, 2022

From previous discussions, my intuition here is to think about r.importValue("/something", "name") as equivalent to <script type="module" src="/something"><script>. This way, you can't not observe that you're being executed inside a ShadowRealm. @rwaldron do we have any tests about this? @erights @mhofman do you have any opinion on this?

@leobalter
Copy link
Member

@caridy please see #364 (comment)

if we do r.importValue("/something") this way, we may assume importValue won't ever do any sort of serialization of the module namespace, and perhaps this could be featured in some ShadowRealm.prototype.import to return a static namespace representation.

@caridy
Copy link
Collaborator

caridy commented May 27, 2022

@leobalter I have updated my example, but that's not the important part, I just forgot to add the second argument.

@codehag
Copy link
Contributor

codehag commented May 27, 2022

The null referencing script for dynamic import in html occurs in such cases:

<button onclick="import(`my-module.js`)">click me</button>

This way, you can't not observe that you're being executed inside a ShadowRealm.

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.

@littledan
Copy link
Member

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.

@caridy
Copy link
Collaborator

caridy commented Feb 8, 2024

This is a very old issue, and the spec is not using HostImportModuleDynamically anymore. I believe this was addressed a while ago, currently, the spec is doing this following as part of the importValue routine:

1. Let _referrer_ be the Realm component of _evalContext_.
1. Perform HostLoadImportedModule(_referrer_, _specifierString_, ~empty~, _innerCapability_).

@nicolo-ribaudo probably have more details. I'm closing the issue, as it seems that when invoking HostLoadImportedModule we always have a valid referrer value pointing to the realm associated to the shadow realm instance.

@caridy caridy closed this as completed Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants