-
Notifications
You must be signed in to change notification settings - Fork 44
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
Stop using the "incumbent settings object" #60
Comments
Probably uses current global in Gecko |
I've written some (quite fun...) tests which confirm that current seems more correct: web-platform-tests/wpt#4722 @mkruisselbrink can I hand this over to you for test review + spec fixing? |
Thanks, had a look at the tests. Also played around a bit more with it. Edge seems to indeed (incorrectly) not serialize the origin in the URL. But it's still possibly to tease out what origin it associates with the blob URL by trying to XHR the resulting URL. And with that it seems that only an XMLHttpRequest instance created using the top (web-platform.test:8000) origin is able to read the blob. So at least edge isn't using the current settings object, but other than that the various settings objects always confuse me. Is that actually the incumbent settings object, or is that entry settings object? Either way it still seems reasonable to change the spec to "current" settings object. |
Very interesting. Maybe you could submit extra tests so that we test both the serialization and XHR's ability to access. But yes, I agree we should go ahead with changing the spec and merging the tests. |
web-platform.test:8000 is the entry global, BTW; see https://github.com/w3c/web-platform-tests/pull/4722/files#diff-1449b34f69ff3a67cb389f72c59c4496R10 |
Helps with w3c/FileAPI#60. Spec changed in w3c/FileAPI#67
See whatwg/html#1430 for background.
The text was updated successfully, but these errors were encountered: