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.

Sign up for GitHub

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

Jump to bottom

Consider not special casing document's address handling when loading javascript: #1565

Closed
smaug---- opened this issue Jul 18, 2016 · 3 comments
Closed

Consider not special casing document's address handling when loading javascript: #1565

smaug---- opened this issue Jul 18, 2016 · 3 comments
Labels
interop Implementations are not interoperable with each other topic: javascript: URLs topic: navigation

Comments

@smaug----
Copy link

smaug---- commented Jul 18, 2016 •
edited
Loading

See https://bugzilla.mozilla.org/show_bug.cgi?id=1281375

Testcase is in https://bugzilla.mozilla.org/show_bug.cgi?id=1281375#c0
(couldn't figure out how to copy that data: url to github sanely)
I think blink's behavior is quite surprising, and I don't see the need for special casing javascript:.
@dominiccooney
Copy link

I guess this special-casing allows more lenient access to the navigated documents than the SOP would give to javascript: URLs? It would be interesting to do the archaeology on the special-casing.

@annevk
Copy link
Member

annevk commented Jul 20, 2016

Note that override URL is also used by document.open() and document.write() in some situations.

@annevk annevk mentioned this issue Feb 17, 2017
Merged
annevk added a commit that referenced this issue Feb 22, 2017
@annevk
Remove javascript URL case from <a>/<area>/Location hash setter
deea9fb 
It makes no sense to just special case them in this IDL attribute
anymore, if it ever did.

Javascript URLs might come up again for the Location object 
per #1565, but for now they cannot be represented there and
the other case should be aligned with the URL Standard, which
changes per whatwg/url#254.
@domenic domenic added the interop Implementations are not interoperable with each other label Jun 6, 2018
@domenic domenic mentioned this issue Dec 11, 2018
Merged
@jyasskin
Copy link
Member

jyasskin commented Dec 12, 2018 •
edited
Loading

FYI, #4205 (comment) keeps special-casing the address for javascript: URLs. I don't know enough to say which is the right text here.

alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@annevk
Remove javascript URL case from <a>/<area>/Location hash setter
065a26c 
It makes no sense to just special case them in this IDL attribute
anymore, if it ever did.

Javascript URLs might come up again for the Location object 
per whatwg#1565, but for now they cannot be represented there and
the other case should be aligned with the URL Standard, which
changes per whatwg/url#254.
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@jyasskin @mustaqahmed
Specify a navigated-to new document's URL
ca2b58c 
The "URL that was originally to be fetched" isn't clear about which URL
that actually was. This makes it clear that we use the request's current
URL when available, or the response's URL when not.

For javascript: URLs, this fixes them to match 2/3 browser behavior.
6440cca regressed the algorithm by
deleting the actual usage site of the address variable. This change
reintroduces the use of address, although in a simpler way, by appending
address to the request's URL list, instead of using the "override URL"
concept which was removed.

Fixes whatwg#3953.

Closes whatwg#1565 by preserving the special case; discussions there and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1281375#c7 indicate that
the special case is more web-compatible.

Tests:

* https://github.com/web-platform-tests/wpt/blob/7ed525acfb4133c1177fdb1ff8477e2a6469e6b4/html/browsers/history/the-location-interface/location_hash.html#L24
* https://github.com/web-platform-tests/wpt/blob/7ed525acfb4133c1177fdb1ff8477e2a6469e6b4/html/semantics/embedded-content/the-iframe-element/iframe_javascript_url_01.htm
* web-platform-tests/wpt#14288
* web-platform-tests/wpt#14316
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@jyasskin @mustaqahmed
Specify a navigated-to new document's URL
0920e22 
The "URL that was originally to be fetched" isn't clear about which URL
that actually was. This makes it clear that we use the request's current
URL when available, or the response's URL when not.

For javascript: URLs, this fixes them to match 2/3 browser behavior.
6440cca regressed the algorithm by
deleting the actual usage site of the address variable. This change
reintroduces the use of address, although in a simpler way, by appending
address to the request's URL list, instead of using the "override URL"
concept which was removed.

Fixes whatwg#3953.

Closes whatwg#1565 by preserving the special case; discussions there and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1281375#c7 indicate that
the special case is more web-compatible.

Tests:

* https://github.com/web-platform-tests/wpt/blob/7ed525acfb4133c1177fdb1ff8477e2a6469e6b4/html/browsers/history/the-location-interface/location_hash.html#L24
* https://github.com/web-platform-tests/wpt/blob/7ed525acfb4133c1177fdb1ff8477e2a6469e6b4/html/semantics/embedded-content/the-iframe-element/iframe_javascript_url_01.htm
* web-platform-tests/wpt#14288
* web-platform-tests/wpt#14316
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interop Implementations are not interoperable with each other topic: javascript: URLs topic: navigation
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dominiccooney @jyasskin @domenic @annevk @smaug----