fix: panel position in scrolled container

[salomvary]

Make sure panel positioning is correct if the panel is placed in a container that has been scrolled
horizontally or vertically.

Summary

When the panel is positioned in a scrollable container (the body or another scrollable element) the panel position is wrong if the container has actually been scrolled as explained in this issue comment: #763 (comment)

Result

• Run yarn workspace @algolia/autocomplete-example-panel-placement-positioned start
• Slightly scroll one or more of the four scrollbars
• Type "a" in one of the autocomplete inputs

I've tested this in latest Firefox, Chrome and Safari on macOS. I am not entirely sure what browsers should be supported (there seems to be no documentation on that, and .browserslistrc is not very helpful for humans), but this way of positioning seems to be cross-browser, cross-platform.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 54775cb:

Sandbox	Source
@algolia/autocomplete-example-github-repositories-custom-plugin	Configuration
@algolia/autocomplete-example-instantsearch	Configuration
@algolia/autocomplete-example-playground	Configuration
@algolia/autocomplete-example-preview-panel-in-modal	Configuration
@algolia/autocomplete-example-starter-algolia	Configuration
@algolia/autocomplete-example-starter	Configuration
@algolia/autocomplete-example-reshape	Configuration
@algolia/autocomplete-example-vue	Configuration

[Haroenv]

I'm a little confused, are you suggesting to revert #1336 ?

[salomvary]

I'm a little confused, are you suggesting to revert #1336 ?

Well, it's a bit more complicated than that :D

1.19.6 has actually two problems with positioning, both coming from packages/autocomplete-js/src/getPanelPlacementStyle.ts:

1. Panel positioning is broken when when autocomplete is placed inside a positioned container. That's what I tried to fix in fix: panel position in positioned container (#763) #1336.
2. Panel positioning is also broken when autocomplete is placed inside a scrolled container that has actually been scrolled. I'm trying to fix that in this PR, but apparently, fix: panel position in positioned container (#763) #1336 made this broken in a different way :)

Let me illustrate on yarn workspace @algolia/autocomplete-example-panel-placement start after adding an element that makes the entire page scrollable by running this on the browser dev console: document.body.insertAdjacentHTML('beforeend', '<div style="height: 150%; width: 150%"></div>').

This is how on the v1.19.6 tag looks like - broken because too far left:

And the on current next (8d4b512102) which includes #1336 - broken because too far down:

And on salomvary:fix-positioning-when-scrolled (54775cb9b25) - seems fine:

The options I see are:

• Merge this pr
• Revert fix: panel position in positioned container (#763) #1336 and then create a new commit combining fix: panel position in positioned container (#763) #1336 and this pr, maybe do a more testing

Testing this is quite a tedious manual job, and given the lack of clarity on to-be-supported browsers, it is impossible for a human to tell if this does not break something in a browser where it should not. The jest tests are of little use here as one would need a browser engine that actually renders layout, which jsdom is not.

[Haroenv]

Yes, that makes sense, but I'm somewhat confused what you mean that 1.19.6 has to do with this? your previous PR hasn't been released yet, is the scrollIntoView interfering somehow?

[Haroenv]

browser support is evergreen browsers in general, there's never been an explicit user request for a browser to supported by autocomplete. Do you have specific browsers in mind that aren't tested? older safari? ie?

[salomvary]

browser support is evergreen browsers in general, there's never been an explicit user request for a browser to supported by autocomplete. Do you have specific browsers in mind that aren't tested? older safari? ie?

I guess "evergreen browsers" in practice translates to latest Chrome, Safari, Firefox and Edge on desktop? Mobile gets wild, and you might want to be specific with operating systems too. In any case, I can manually test on those on macOS but I might not go the long way and booting up Windows somewhere:)

Btw there is also browserslist configured with defaults, which claims support for things like Chrome 109, released over 3 years ago. Or a 4+ years old Firefox 102.

$ yarn browserslist
yarn run v1.22.22
$ /Users/mrc/Projects/shepherd/autocomplete/node_modules/.bin/browserslist
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
and_chr 126
and_ff 127
and_qq 14.9
and_uc 15.5
android 126
chrome 126
chrome 125
chrome 124
chrome 123
chrome 109
edge 126
edge 125
edge 124
firefox 127
firefox 126
firefox 125
firefox 102
ios_saf 17.5
ios_saf 17.4
ios_saf 16.6-16.7
ios_saf 15.6-15.8
kaios 3.0-3.1
kaios 2.5
op_mini all
op_mob 80
opera 111
opera 110
opera 109
safari 17.5
safari 17.4
samsung 25
samsung 24
✨  Done in 0.75s.

But I personally don't care about anything but most recent versions of mainstream desktop browsers. No request for anything exotic/ancient :)

I'm somewhat confused what you mean that 1.19.6 has to do with this? your previous PR hasn't been released yet, is the scrollIntoView interfering somehow?

1.19.6 is the currently released version, and both "positioning inside a positioned container" and "positioning inside a scrollable container" are broken on that version.

My two PRs together fix both. The first PR (#1336) fixes "positioning inside a positioned container" and makes "positioning inside a scrollable container" broken in a different way. The second PR (this one, #1338) fixes
1.19.6 is the currently release version, and both "positioning inside a positioned container" and "positioning inside a scrollable container" when combined with (#1336).

Sorry for the confusing mess, I was initially confused by these being two separate problems but implemented at the same place, and I also did not fully understand the implementation at first.

If there are available resources to throw at this, or someone wants to volunteer, I'd recommend adding end-to-end tests using Playwright, Cypress or something similar to verify correct rendering of such details, but I'm afraid won't be the person doing that :)