-
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
What should happen when setting location.hash = location.hash
?
#7386
Comments
Setting |
We can update the spec to match 2/3 browsers; I'll try to work on that soon. |
Thanks. In that case, I'll submit a patch to make Firefox's behavior match Chrome and Safari's. I also have a patch to extend the scroll-to-anchor-name.html WPT test to cover this |
Note that the new value post-parsing is what is being compared to the old value. This makes sense, but also means it's slightly more involved. It might be worth testing that as well with a value such as |
This adds a special case which is necessary for compatibility with deployed content, and implemented in 2/3 engines. Closes #7386.
This adds a special case which is necessary for compatibility with deployed content, and implemented in 2/3 engines. Closes #7386.
…he current hash, a=testonly Automatic update from web-platform-tests Test using location API to navigate to the current hash See whatwg/html#7386. -- wpt-commits: 1e5972db2fb855ac1a1685b95b11a5f7159e4c4c wpt-pr: 32291
…he current hash, a=testonly Automatic update from web-platform-tests Test using location API to navigate to the current hash See whatwg/html#7386. -- wpt-commits: 1e5972db2fb855ac1a1685b95b11a5f7159e4c4c wpt-pr: 32291
This adds a special case which is necessary for compatibility with deployed content, and implemented in 2/3 engines. Closes whatwg#7386.
This behavior was already agreed upon in <whatwg/html#7386>, but bug 1544428 was an implementation edge case needing to be fixed. An exception is when the fragment contains a directive, in which case a difference in `hasRef` is sufficient, to retain existing behavior WRT directives. Although bug 1544428 is about popstate, hashchange was erroneously being dispatched, as well, which this patch fixes. Some tests that depended on the old behavior are updated. Differential Revision: https://phabricator.services.mozilla.com/D225567 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1544428 gecko-commit: 80bb463edec5a6e91258e1d507196255c60070f4 gecko-reviewers: jjaschke, dom-core, sessionstore-reviewers, dao, farre
…ges. r=jjaschke,dom-core,sessionstore-reviewers,dao,farre This behavior was already agreed upon in <whatwg/html#7386>, but bug 1544428 was an implementation edge case needing to be fixed. An exception is when the fragment contains a directive, in which case a difference in `hasRef` is sufficient, to retain existing behavior WRT directives. Although bug 1544428 is about popstate, hashchange was erroneously being dispatched, as well, which this patch fixes. Some tests that depended on the old behavior are updated. Differential Revision: https://phabricator.services.mozilla.com/D225567
…ges. r=jjaschke,dom-core,sessionstore-reviewers,dao,farre This behavior was already agreed upon in <whatwg/html#7386>, but bug 1544428 was an implementation edge case needing to be fixed. An exception is when the fragment contains a directive, in which case a difference in `hasRef` is sufficient, to retain existing behavior WRT directives. Although bug 1544428 is about popstate, hashchange was erroneously being dispatched, as well, which this patch fixes. Some tests that depended on the old behavior are updated. Differential Revision: https://phabricator.services.mozilla.com/D225567
This behavior was already agreed upon in <whatwg/html#7386>, but bug 1544428 was an implementation edge case needing to be fixed. An exception is when the fragment contains a directive, in which case a difference in `hasRef` is sufficient, to retain existing behavior WRT directives. Although bug 1544428 is about popstate, hashchange was erroneously being dispatched, as well, which this patch fixes. Some tests that depended on the old behavior are updated. Differential Revision: https://phabricator.services.mozilla.com/D225567 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1544428 gecko-commit: 80bb463edec5a6e91258e1d507196255c60070f4 gecko-reviewers: jjaschke, dom-core, sessionstore-reviewers, dao, farre
…ges. r=jjaschke,dom-core,sessionstore-reviewers,dao,farre This behavior was already agreed upon in <whatwg/html#7386>, but bug 1544428 was an implementation edge case needing to be fixed. An exception is when the fragment contains a directive, in which case a difference in `hasRef` is sufficient, to retain existing behavior WRT directives. Although bug 1544428 is about popstate, hashchange was erroneously being dispatched, as well, which this patch fixes. Some tests that depended on the old behavior are updated. Differential Revision: https://phabricator.services.mozilla.com/D225567
In Firefox, setting
location.hash = location.hash
will scroll the page back to the current anchor's position. In Chrome and Safari, settinglocation.hash = location.hash
is ignored.The HTML Standard's description of the
hash
setter steps does not include a special case for checking whether the new hash is equal to the current hash. My reading of the steps is that the browser should7. Location-object navigate to copyURL
even ifcopyURL
is the same the current URL. In that case, Firefox is following the spec'd behavior and Chrome and Safari are not.https://html.spec.whatwg.org/#dom-location-hash
Here is Chromium's
hash
setter implementation where it bails early if the new hash is equal to the current hash:https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/location.cc;l=203-204;drc=984c3018ecb2ff818e900fdb7c743fc00caf7efe
Steps to reproduce:
location.hash = location.hash
Result:
In Firefox 94, the page scrolls back to the
#Features
anchor position. In Chrome 96 and Safari 15, the page does not scroll.If you replace step 3 with
location.href = location.href
, Firefox, Chrome, and Safari all scroll back to the#Features
anchor position.This difference in behavior causes a webcompat problem reported in this Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1733797
Steps to reproduce:
Result:
In Chrome 96 and Safari 15, you can scroll the page and the fragment of the URL in the address bar changes as you scroll to each document section on the left of the page ("Terms of Service", "Privacy Policy", etc).
In Firefox 94, you can't scroll the page because the page has a scroll event handler that sets location.hash to the current document section's anchor. Firefox can't scroll because it keeps returning to the current anchor's position.
The text was updated successfully, but these errors were encountered: