Closed Bug 1907934 Opened 5 months ago Closed 3 months ago

sap.github.io - Page autoscrolls

Categories

(Web Compatibility :: Site Reports, defect, P2)

Product:
Web Compatibility
Component:
Site Reports
Platform:
Desktop
Windows 10
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: rbucata, Unassigned)

References

(
URL
)

Details

(Keywords: webcompat:needs-diagnosis, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:annoyance
configuration:general
affects:all
branch:release

Environment:
Operating system: Windows 10
Firefox version: Firefox 130.0

Steps to reproduce:

  1. Navigate to: https://sap.github.io/ui5-webcomponents-react/main/?path=/docs/data-display-analyticaltable--docs#infinite-scrolling
  2. Observe how the page scrolls after waiting for a while

Expected Behavior:
The page does not autoscroll

Actual Behavior:
The page autoscrolls

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in Firefox Nightly, and Firefox Release
  • Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/139129

Severity: -- → S3
User Story: (updated)
Keywords: webcompat:needs-diagnosis, webcompat:site-report
Priority: -- → P2

(In reply to Raul Bucata from comment #0)

Environment:
Operating system: Windows 10
Firefox version: Firefox 130.0

Steps to reproduce:

  1. Navigate to: https://sap.github.io/ui5-webcomponents-react/main/?path=/docs/data-display-analyticaltable--docs#infinite-scrolling

The #infinite-scrolling fragment identifier on the end of the URL seems to be what triggers this -- Firefox attempts to scroll the page to display that element. Isn't that what is expected when a fragment ID is provided, though?

I guess the ugliness of the loading/scrolling-to-anchor operation is a result of the page loading incrementally rather than all at once, so when we first display it, the anchor isn't there yet.

FWIW, Safari also does something similar (although its behavior seems slower/jankier than ours, at least on my machine). Chrome just doesn't seem to attempt to scroll to the given fragment.

I had a look at this, and I'll just close this as WONTFIX. There is a difference in browser behaviors here, but we match Safari, and I think we're doing the right thing either way. This isn't a high severity issue either way.

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.