Open Bug 1733797 Opened 3 years ago Updated 2 years ago

Location's hash setter might need to no-op when set to the same value

Categories

(Core :: DOM: Window and Location, defect, P3)

Firefox 92
Unspecified
All
defect

Tracking

()

ASSIGNED
Tracking Status
firefox-esr91 --- affected
firefox94 --- wontfix
firefox95 --- affected
firefox96 --- affected

People

(Reporter: bug-str, Assigned: cpeterson)

References

Details

(Keywords: parity-chrome)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

If I open this link:
https://lithic.com/legal#terms
or
https://lithic.com/legal
scrolling of the page does not work.

Actual results:

There is a scroll bar, but it doesn't not move.

Opening a link with any other #portion, e.g. https://lithic.com/legal#privacy-policy
(or clicking on such a link at the top left portion of the page) clears the scrolling problem.
However if after that, I scroll all the way up, the scrolling is again stuck.

Expected results:

I should be able to scroll the page even if it has some defect in its script, especially since it works in other browsers.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

The page has a scroll event handler which repeatedly sets window.location.hash to the anchor of the section that's currently in view (so, for example, if https://lithic.com/legal#terms is loaded and you scroll down, the terms section is still in view so it performs window.location.hash = "#terms".

It looks like, in Firefox, assigning to window.location.hash a value which matches the current anchor, causes the anchor location to be scrolled into view (i.e. we scroll back to the top of the section), whereas in Chrome it does not.

I'm not sure which behaviour is correct. Moving to DOM: Navigation for further comment.

Component: Panning and Zooming → DOM: Navigation
Component: DOM: Navigation → DOM: Window and Location

Thanks Botond for debugging!

Per the setter description at https://html.spec.whatwg.org/#dom-location-hash Firefox is correct. However, given that Chrome and Safari appear to have an early return, the simplest way forward would probably be changing Firefox and the standard.

Anny, is this something that would interest you?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(agakhokidze)

We should probably investigate if this applies to other setters as well. And maybe also how this works with <a> and such for good measure.

Summary: Broken scrolling on a specific lithic.com page → Location's hash setter might need to no-op when set to the same value

Not sure if I have time in the near future to work on this, but I'll add it to my list of bugs I could work on if im looking for more tasks.

Flags: needinfo?(agakhokidze)
Severity: -- → S2
Keywords: parity-chrome

@ Anny, do you mind filing the spec issue?

Nika says this bug will be easy to fix, but we should get the ball rolling on the spec change. We'll also want to write a WPT for the new scroll behavior.

If this bug won't get fixed soon, we can file a webcompat.com issue and ask the Webcompat team to reach out to lithic.com's web developers.

Nika shared this link to Chrome's early return when the new window.location.hash value which matches the current anchor:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/location.cc;l=203-204;drc=984c3018ecb2ff818e900fdb7c743fc00caf7efe

Flags: needinfo?(agakhokidze)
Priority: -- → P3

Clearing needinfo because Anny is working on some more urgent bugs.

Severity: S2 → S3
Flags: needinfo?(agakhokidze)
Assignee: nobody → cpeterson
Status: NEW → ASSIGNED
OS: Unspecified → All

These tests will be updated in the next changeset when Firefox is fixed to match the behavior of Chrome and Safari.

hash is a UTF-8 string, so we don't need to cast chars to char16_t.

Depends on D132546

I filed an HTML spec issue asking what should happen when setting location.hash = location.hash:

https://github.com/whatwg/html/issues/7386

Thanks Chris!

You need to log in before you can comment on or make changes to this bug.