In page anchor links should scroll smoothly instead of jump instantly

NEW
Unassigned

Status

()

--
enhancement
14 years ago
3 months ago

People

(Reporter: gauthierm, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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?
(Reporter)

Comment 2

14 years ago
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
Duplicate of this bug: 539547
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
Created attachment 481753 [details] [diff] [review]
fix

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.

Updated

8 years ago
Attachment #481753 - Flags: approval2.0+

Comment 12

8 years ago
This doesn't apply cleanly any more.
Whiteboard: not-ready
Created attachment 523504 [details] [diff] [review]
fix v2

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
Created attachment 524888 [details] [diff] [review]
fix v3

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.

Comment 18

8 years ago
(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.

Comment 20

6 years ago
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".

Comment 22

4 years ago
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.

Comment 25

6 months ago
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?

Comment 26

3 months ago
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?
You need to log in before you can comment on or make changes to this bug.