Keep the reader's place when a filter narrows the product list

[boo-code]

Questions	Answers
Description?	Clicking a faceted search filter jumps the page back to the top, so the shopper loses sight of the products they were reading. The listing update handler ends with an unconditional window.scrollTo(0, 0), which runs for every product list refresh - narrowing a filter as much as turning a page. Paging is the one case where the jump makes sense, because the products the shopper was looking at are gone; a filter keeps most of them. The scroll now happens only for pagination, and it targets the list header rather than the very top of the document.
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#38802.
How to test?	On a category with enough products to scroll, scroll down to the products and tick a filter. Before: the page returns to the top. After: the position is kept and only the list is replaced. Then click a pagination link: the list header is scrolled into view, as before.
Sponsor company

Where it comes from

_dev/js/listing.js:

prestashop.on('updateProductList', (data) => {
  updateProductListDOM(data);
  window.scrollTo(0, 0);
});

Every route into the listing ends here - the filter checkboxes, the sort select, "clear all", the facet links and the pagination links, since in this theme pagination links also carry js-search-link. So the same jump is applied to all of them.

The behaviour this aligns with

The Hummingbird theme already separates the two. It scrolls in the pagination branch only, and to the list header:

} else if (target.closest(listing.paginationLink)) {
  event.preventDefault();
  const listHeader = document.querySelector(listing.listHeader);
  if (listHeader) {
    listHeader.scrollIntoView({block: 'start', behavior: 'auto'});
  }

This change gives the classic theme the same rule. Pagination is told apart by the link sitting inside nav.pagination, which is what templates/_partials/pagination.tpl renders, rather than by a new selector.

Scope

Read from the sources; assets/ is not tracked here, so this is a _dev only change. The report is filed against 8.2, and the handler is unchanged on develop, which is why it is still worth fixing rather than closing as outdated. I have not run the classic theme on a live shop for this - the mechanism is a single unconditional call in the handler, and the contrast with Hummingbird is in the code above.

[ps-jarvis]

Hello @boo-code!

This is your first pull request on classic-theme repository of the PrestaShop project.

Thank you, and welcome to this Open Source community!