-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
window.location should be removed #3520
Comments
In that case, should I guess you could argue that Also, how do we get the URL of the main module, after this change? |
@nayeemrmn Can you give us some examples to show how this proposal works better than current implementation? |
This is about the compatibility problem with the current usage of The current one offers no interoperability, and yet it's disguised as a web API in the global namespace. The proposal offers interoperability for any code that assumes |
It turns out it is even more complicated...
Chrome, loaded from http URL:
Chrome, loaded from file URL:
|
Hmm, we could certainly easily match the worker behaviour in either case but not handling |
l actually believe that our current value is fine; |
Yes the
As I've explained, there is no usable relationship between Deno's main module URL and the web's page URL. The assumed meaning of this API on the web is something Deno has no concept of. Can anyone give an isomorphic use case? |
Update: we've discussed this issue with @piscisaureus and @ry and came to conclusion that even though Deno's That said; we'll need to update module resolution algorithm for local files before this issue can be closed (ref #3401) |
@bartlomieju Can you provide the reasoning behind the decision (removal of location)? Is this about the security concern? |
@kt3k long story short; in browser |
@bartlomieju Thank you very much! Makes sense to me. |
Currently
window.location
is the URL of the main module. A while ago @kitsonk agreed with me that this isn't ideal.It should be the CWD with a trailing slash as a file URL. The CWD is where resources get resolved from so it is actually compatible with the current document in browsers. It would lend some sanity to things like #2150 and be part of a clearly isomorphic set of APIs.It should be removed outright. See #3520 (comment) and #3520 (comment).
The text was updated successfully, but these errors were encountered: