Open Bug 279629 Opened 19 years ago Updated 1 year ago

In page anchor links should scroll smoothly instead of jump instantly

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
enhancement

Tracking

()

People

(Reporter: gauthierm, Unassigned)

References

(
URL
)

Details

Attachments

(1 file, 2 obsolete files)

fix v3
4.44 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

In page anchor links should scroll smoothly instead of jumping instantly to the
anchor position. The scrolling should be slow enough to be noticeable so the
user knows where on the page they are headed. The scrolling should be fast
enough that it doesn't distractthe user unnecessarily.

Reproducible: Always

Steps to Reproduce:
1. On the provided example page, click the view purchasing info link

Actual Results:  
Page instantly jumps to the anchor location leaving the user slightly confused
about what they just did.

Expected Results:  
Scrolled smoothly to the anchor location so the user makes an association
between what they clicked and where they ended up.
Don't we already do this if smoothscrolling is enabled?
This page is an example of what I was trying to explain in my initial bug report.

http://www.kryogenix.org/code/browser/smoothscroll/
(In reply to comment #1)
> Don't we already do this if smoothscrolling is enabled?

No, not for anchors.
Assignee: events → nobody
QA Contact: ian → events
Carrying over additional info from bug 539547, since I duped it against this:

At the moment, anchor links jump directly to the location on the page you're
loading, which is confusing people. They might not notice that the scroll bar
indicates that they are actually halfway down a page.

We should have better affordances for this behavior, the easiest way to fix is
probably to do a smooth scrolling event (timed so it doesn't take more than,
say, ~0.3s no matter how long the page is). That way, there's a semblance of
movement down the page, and users will realize that they are being
automatically placed further down on the page.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch fix (obsolete) — — Splinter Review 
It's easy to have scroll-to-anchor be a smooth scroll if smooth scrolling is enabled.
Assignee: nobody → roc
Attachment #481753 - Flags: review?(matspal)
Comment on attachment 481753 [details] [diff] [review]
fix

r=mats
Attachment #481753 - Flags: review?(matspal) → review+
So how should the patch work.
I enabled smooth scrolling, but couldn't get smooth scroll to #anchor.
The testcase was a bugzilla page where I clicked "edit" link in the
status line near the top of the page.
I don't know, my testcase works for me.
Attachment #481753 - Flags: approval2.0? → approval2.0+
Re the [needs landing]...the patch no longer applies at all.
Yeah, and it modifies nsIPresShell so it'll be a pain to land it for FF4 now. Let's not.
Attachment #481753 - Flags: approval2.0+
This doesn't apply cleanly any more.
Whiteboard: not-ready
Attached patch fix v2 (obsolete) — — Splinter Review 
Bug 601352 rotted this pretty bad, but mainly by duplicating a lot of what was in this patch. So the new patch is a lot smaller :-).
Attachment #481753 - Attachment is obsolete: true
Attached patch fix v3 — — Splinter Review 
Fixes build failure
Attachment #523504 - Attachment is obsolete: true
I landed this again but backed it out caused test failures:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1302542025.1302542772.10128.gz&fulltext=1
301 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug388019.html | we scroll at all - didn't expect 0, but got it
302 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug388019.html | we scroll at least 4000 pixels

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1302542108.1302543382.12804.gz&fulltext=1
1643 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/docshell/test/chrome/test_bug360511.xul | We're at the top of the page but we should be at the bottom
1658 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/docshell/test/chrome/test_bug360511.xul | We're at the top of the page but we should be at the bottom

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1302542002.1302542636.9166.gz&fulltext=1
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/content/test/reftest/bug559996.html | image comparison (==)
REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug582940-1.html | image comparison (==)
It looks like those test failures are just tests that scroll to an anchor and expect it to complete instantly.
(In reply to comment #17)
> It looks like those test failures are just tests that scroll to an anchor and
> expect it to complete instantly.

So is there any way for those tests to get notified on when the scrolling is finished?
I think they just need to poll until scrollTop has the correct value.
The tests in bug 868432 might have what was needed here.
I have implemented this functionality as part of Bug 1010538.

When Bug 1010538 lands, the anchor navigation smooth scrolling can be enabled by setting CSSOM-View scroll-behavior CSS property to "smooth".
I would expect using <a href="#top">...</a> for a "Back to top" button to scroll smoothly when the scroll-behaviour of the body set to "smooth". However, scrolling is only smooth if an element matches the fragment identifier.

Currently an element with id="top" will need to be positioned at the top of the page for <a href="#top">...</a> to scroll smoothly to the top of the page while <a href="#">...</a> can never scroll smoothly.
I wonder, if this is (or will be) related to APZ.
scroll-behavior is already hooked up to APZ correctly, so in fixing this one shouldn't need to touch APZ.
So, now that we’ve got the functionality in place for this, (as per comment #21) do we want to flip the switch and have this as default behaviour?
I have visual processing issues, and this kind of scrolling can hurt and can trigger my migraines.

I already disable autoscrolling and smooth scrolling for the same reason. If you can find a way to enable this for users who prefer smooth scrolling, and disable this for users who don't, would that work?
Update on comment #22:
Actually as of now, <a href="#"> works properly if scroll-behavior is set to smooth, but <a href="#top"> jumps instead of scrolling smoothly. So if developers use href="#" everything works as intended, but "#top" is still broken. In Chromium, "#" and "#top" are treated the same and both adjust to scroll-behavior.


This is enough to repro: 

<!doctype html>
<html style="scroll-behavior:smooth">
  <body>
    <a href="#" style="display:block;margin-top:150vh">To # (smooth)</a>
    <a href="#top">To #top (not smooth)</a>
  </body>
</html>
Component: Event Handling → User events and focus handling

While smooth scrolling now works for anchors on the same page (with scroll-behavior: smooth), when navigating to an anchor on a separate page, the page loads directly on the anchor.
In Chromium, the page loads at the top then scrolls down, which I feel is more intuitive.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.