-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Setting the document's address doesn't seem to be correct #3953
Labels
Comments
Yeah, ideally we define document creation more imperatively, but it's a lot of work refactoring all the intertwingledness of the existing text. |
jyasskin
added a commit
to jyasskin/html
that referenced
this issue
Nov 26, 2018
The "URL that was originally to be fetched" isn't clear about which URL that actually is. The choices here are: * The request's URL: The original URL before any redirects. * The request's current URL: The final URL after any redirects, and treating a Service Worker's response as from that URL. * The response's URL: Either the final URL after any redirects, or, if a Service Worker intercepted the fetch and returned a response from a different URL, that different URL. Fixes whatwg#3953.
jyasskin
added a commit
to jyasskin/html
that referenced
this issue
Dec 12, 2018
The "URL that was originally to be fetched" isn't clear about which URL that actually is. The choices here are: * The request's URL: The original URL before any redirects. * The request's current URL: The final URL after any redirects, and treating a Service Worker's response as from that URL. * The response's URL: Either the final URL after any redirects, or, if a Service Worker intercepted the fetch and returned a response from a different URL, that different URL. Fixes whatwg#3953.
domenic
pushed a commit
that referenced
this issue
Dec 18, 2018
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 #3953. Closes #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
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
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
https://html.spec.whatwg.org/#set-the-document's-address has:
This doesn't sound correct, with respect to request vs. response URLs.
The text was updated successfully, but these errors were encountered: