Provide way to defeat smooth scroll to top of page with AJAX page loading

Does views in D8 core do this too? Not sure if there's a core issue yet.

Good point.. I tried to find a module which did this in Drupal & came up with https://www.drupal.org/sandbox/souless/2349477

Not likely one that folks use much. Would be good to find where this should be placed. Marking it postponed for now.

FTR this comes from Drupal.ajax.prototype.commands.viewsScrollTop:

  Drupal.ajax.prototype.commands.viewsScrollTop = function (ajax, response, status) {
    // Scroll to the top of the view. This will allow users
    // to browse newly loaded content after e.g. clicking a pager
    // link.
    var offset = $(response.selector).offset();
    // We can't guarantee that the scrollable object should be
    // the body, as the view could be embedded in something
    // more complex such as a modal popup. Recurse up the DOM
    // and scroll the first element that has a non-zero top.
    var scrollTarget = response.selector;
    while ($(scrollTarget).scrollTop() == 0 && $(scrollTarget).parent()) {
      scrollTarget = $(scrollTarget).parent();
    }
    // Only scroll upward.
    if (offset.top - 10 < $(scrollTarget).scrollTop()) {
      $(scrollTarget).animate({scrollTop: (offset.top - 10)}, 500);
    }
  };

We could consider adding a global option to choose between the animate() action and a simple jump. Thoughts?

I would hazard to suggest that the primary issue (induced nausea) is related to the scroll speed, and probably that middle-ground speed where it's not slow enough that it's a non-issue, and it's not fast enough that it doesn't trigger.

So my suggestion would be to keep the autoscroll (and I'd argue it is more of an autoscroll than a smoothscroll) and to:
- Speed it up; reduce 500 to something like 200
- Make the speed consistent; so the animate time scales with the distance travelled, meaning it's always snappy

For me this would keep the benefit of autoscroll, that being it's less jaring than insta-jump and and less disorienting (can't easily tell if you've gone up or down the page), whilst mitigating against the nausea issue, and it also takes the burden off site admins from the decision by giving something that should be good for both situations.

Perhaps Charles Belov could chime in on this idea.

Adding the related D8 core issue. Over at #2316205-72: Provide a way to disable animations for a11y the discussion has turned to designing animations which use the new prefers-reduced-motion CSS media query.

re: #6 - prefers-reduced-motion can be targeted with JS matchMedia, so you could choose to animate or not that way.

re: #7 - There isn't very much published information (yet) about how to assess animations for how serious they are. Do you have any references about it? The idea of a safer speed seems very subjective, and not likely to be safe for all users. Ensuring that it can still function without any animation at all, and respecting OS-level user preferences via prefers-reduced-motion sounds like a safer bet.

I've not heard of prefers-reduced-motion before, is this similar to the dnt (do not track) request header?

If so, then yes this sounds like a suitable compromise.

All you need to do is copy/paste ajax_view.js into your own theme, edit as you like, and have Views use your version rather than the one provided by the module. Somewhat similar to how a theme function would be extended.

Feel like this isn't a support request anymore, perhaps set it as a task until it's decided what to do?

Lets move forward with prefers-reduced-motion media query. Browser support for that is growing.

We can introduce a matchMedia() check in Drupal.ajax.prototype.commands.viewsScrollTop.

We should do this in D8 core too. Normally we'd fix D8 first, then backport it. But in this case it's D8 core and D7 contrib so, so how does that work.... separate issues?

Fixing tagging.

I posted a patch for Views on a drupalorg issue. It hasn't yet been tested -- comments welcome. It's currently installed on a development copy of drupal.org, and can be tested by following the links/instructions on:
#3208119-6: Respect prefers-reduced-motion on list pages

The patch on the above issue has been slightly changed, and has now been reviewed/tested on that other issue, so I'm going to upload it here and at least for the moment, mark it RTBC.

See #3208119-8: Respect prefers-reduced-motion on list pages

Please credit:
https://www.drupal.org/u/mherchel (mherchel)
https://www.drupal.org/u/mikemai2awesome (mikemai2awesome)

for help on the above patch and testing.

Shouldn't be approving self-written patches. Need someone else to review.

True. The patch was tested by the people noted in #18, but the code has not been reviewed. Sorry about that!

window.matchMedia() is not available in IE 9, https://caniuse.com/mdn-api_window_matchmedia, does Views have any guarantees that front-end JS won't break in IE 9?

Has anyone tested for this in Drupal 8+ core? It looks like this issue may be present: https://git.drupalcode.org/project/drupal/-/blob/821ab2b02d683f657d413ff...

I do not use IE and I have no idea what the current version of IE is or whether we support it. Actually, isn't it all "Edge" now? Should we care about IE9?

And yes, I think this issue exists in Core. There is a meta about this for D8 core (already listed as Related to this one):
#2928103: [policy, no patch] Use "prefers-reduced-motion" media query to disable animations
Although I would note that that core meta doesn't yet say anything about Views that I can see.

We don’t need to support IE9 For Drupal.org either. If Views for Drupal 7 promises IE 9 support, we might need to check that window.matchMedia() exists before calling it.

I do not see anything special in the Views 7 documentation https://www.drupal.org/docs/7/modules/views about browser support.

Nothing in the README either https://git.drupalcode.org/project/views/-/blob/7.x-3.x/README.txt

Or on the project page.

Could the patch be changed to conditionally use window.matchMedia() based upon its availability?

OK. Here's a new patch (completely untested). Should probably be tested on both IE9 and a modern browser.

I based the if exists check on
https://www.w3docs.com/snippets/javascript/how-to-check-if-function-exis...
and other similar web search hits on "function exists javascript".

If someone wants to test, I have installed this patch on a dev site. To test:

a) Visit https://contribguide-drupal.dev.devdrupal.org/community/contributor-guid...

b) Enter the user name and password for htaccess: drupal/drupal

c) Scroll to bottom of page and use the pager to go to the next/previous page. You should see:
- If you have "Prefer reduced motion" turned off, or you are using an older browser like IE9, the page will have animated scrolling back to the top.
- If you have "Prefer reduced motion" turned on, the page will scroll to the top without animation.

Note: On Chrome you can emulate turning on "prefer reduced motion" in the developer tools:
1. Right click and choose Inspect.
2. Find the "Rendering" settings (on my screen it is in the bottom section of the Inspect area, to the right of Console and What's New.
3. Under Rendering, you'll find a setting that says "Emulate CSS media feature prefers-reduced-motion", which you can turn on or off. You do not need to reload the whole page after changing the setting, just go back into the page area and try the pager at the bottom.