279629 - In page anchor links should scroll smoothly instead of jump instantly

Status: NEW

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

Description

[Michael Gauthier [:gauthierm]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Don't we already do this if smoothscrolling is enabled?

Comment 2

[Michael Gauthier [:gauthierm]]

This page is an example of what I was trying to explain in my initial bug report.

http://www.kryogenix.org/code/browser/smoothscroll/

Comment 3

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #1)
> Don't we already do this if smoothscrolling is enabled?

No, not for anchors.

Comment 5

[Alex Limi (:limi) — Firefox UX Team]

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

It's easy to have scroll-to-anchor be a smooth scroll if smooth scrolling is enabled.

Comment 7

[Mats Palmgren (inactive)]

Comment on attachment 481753 [details] [diff] [review]
fix

r=mats

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know, my testcase works for me.

Comment 10

[Jonathan Watt [:jwatt]]

Re the [needs landing]...the patch no longer applies at all.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, and it modifies nsIPresShell so it'll be a pain to land it for FF4 now. Let's not.

Comment 12

[(no longer active)]

This doesn't apply cleanly any more.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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 :-).

Comment 14

[(no longer active)]

So I landed this again <http://hg.mozilla.org/projects/cedar/rev/ffde95eff6f4> and backed it out <http://hg.mozilla.org/projects/cedar/rev/f062236233bf> because of build failures: <http://tinderbox.mozilla.org/showlog.cgi?log=Cedar/1302289819.1302291809.7639.gz>

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v3

Fixes build failure

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 (==)

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It looks like those test failures are just tests that scroll to an anchor and expect it to complete instantly.

Comment 18

[(no longer active)]

(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?

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think they just need to poll until scrollTop has the correct value.

Comment 20

[Thomas Stache]

The tests in bug 868432 might have what was needed here.

Comment 21

[:kip (Kearwood Gilbert)]

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

[Taye A]

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.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I wonder, if this is (or will be) related to APZ.

Comment 24

[Markus Stange [:mstange]]

scroll-behavior is already hooked up to APZ correctly, so in fixing this one shouldn't need to touch APZ.

Comment 25

[Robin Whittleton]

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

[MarjaE]

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?

Comment 27

[Jonas Kuske]

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>

Comment 28

[angheloc]

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.