window scrolling in Safari

[spacepolice10]

I just wonder...

Hi, we talked here about Safari already and even fixed some stuff. It was a pleasure. Thank you. Let's talk again

I have an app with a large list of items. And I use initialOffset with initialIndex to get pixel perfect restoring of position in the list when user goes back. This method does not work in mobile Safari for some reasons. The only way to achieve it is to use div instead of document.documentElement but of course it has some caveats and Safari obviously behaves differently with such component

Am I understand correctly that to get proper scrolling restoration I must sacrifice:

1. Browser's default behavior of hiding the search bar when scrolling down
2. Default iOS'es ability to scroll up to the top of the page by tapping top left corner of the display

Or someone figured out how to use div and preserve these features? Or restore position correctly using window as a scrolling container?

[oleggrishechkin]

How initialOffset/initialIndex work now in safari in your case?

[spacepolice10]

In Safari for desktop it works just perfectly. I get index of element and its getBoundingRect.top() on click and store it in sessionStorage. Every desktop browser gets everything right and take me to the correct position always. Mobile Safari works as intended with 50% chance. Half of clicks on back button get me at the right place and half misses for about 400-1000px

[oleggrishechkin]

You can try to use scrollToIndex manually in useEffect instead of initialIndex. Maybe it can help.

const ref = useRef();

useEffect(() => {
  ref.current.scrollToIndex(getIndex(), true, getOffset());
}, []);

return <ViewportList ref={ref} ... />;

initialIndex should work the same way, but maybe something affects scroll too.

Also I want to replace document.documentElement.scrollTop+= with window.scrollBy() for scrolling but I think it will not help with this scroll issue.

[oleggrishechkin]

@spacepolice10 Hi again! I had some free time and I was able to check my solution above. Shortly, it works. Maybe you need to wrap it in setTimeout like

useEffect(() => {
  setTimeout(() => {
    ref.current.scrollToIndex(getIndex(), true, getOffset());
  }, 100);
}, []);

Looks like some async issue for IOS Safari. Maybe I should handle scroll in next tick after render. I should improve it because it has strange behaviour if you combine initialIndex/initialOffeset with manual scrollToIndex even in Chrome and other non-IOS browsers.

But another problem is item rect.top is different when IOS show address bar and not (while scrolling). So you may need to calculate difference it by yourself.

And you shold use netative rect.top as offset (const offset = -rect.top;) (I hope you use it this way)

[spacepolice10]

Hiii )

Thank you again. Yep, I use it that way. Even more, I applied useEffect for all browsers and turned off initialIndex etc...

Works quite well but you're right, it is important to calculate viewport height change. Anyway, feels much more stable and accurate. Really appreciate your help

[oleggrishechkin]

@spacepolice10 I published v6.3.0-beta.0 with delayed scrollToIndex. Could you check it? I added setTimeout internally for scrollToIndex and also remove scrollIntoView call (I manually calculate scroll delta for scrolling to index)

So, you can remove manual scrollToIndex because initialIndex should work correctly in this case.

[spacepolice10]

Sorry, never seen the notification from GitHub. I'll try beta asap. You mean now it is not necessary to calculate bounding rect top for element I want to scroll to?

Also, I probably wouldn't be really happy with removal of scrollToIndex method. For example. I have a component that has cached data and needs to be scrolled to correct position twice because height of DOM changes after data loading and ViewportList gets me to the top when this happens. In short, I need to call ScrollToIndex twice when there's no fresh content and when it is. But thank you anyway for your hard work at making the best virtual list library for React so far )

[oleggrishechkin]

You can use initialIndex/initialOffset instead on manually call scrollToIndex in timeout because I added timeout internally for IOS Safari.

But you still need to calculate correct scroll offset for item as you do.

return <ViewportList initialIndex={getIndex()} initialOffset={getOffset()} ... />

instead of

const ref = useRef();

useEffect(() => {
  setTimeout(() => {
    ref.current.scrollToIndex(getIndex(), true, getOffset());
  }, 100);
}, []);

return <ViewportList ref={ref} ... />;

[oleggrishechkin]

Also, I probably wouldn't be really happy with removal of scrollToIndex method.

You can use scrollToIndex manually as you wish, but you can remove setTimeout wrapper for scrollToIndex (if you use it only to avoid ios safari scroll issue)

[spacepolice10]

Hi there

Two things to say:

1. I would make timer slightly longer (sometimes mobile Safari jumps 100-150 px incorrect) edit: tested it again, seems to work ok now 🤔
2. I would add the same for desktop. It seems to have pretty same problems in different cases (like updating data in list or loading two lists in parallel)

I will stick with own timer for sometime but the update is nice. Thank you

[oleggrishechkin]

Hi there

Two things to say:

1. I would make timer slightly longer (sometimes mobile Safari jumps 100-150 px incorrect) edit: tested it again, seems to work ok now 🤔
2. I would add the same for desktop. It seems to have pretty same problems in different cases (like updating data in list or loading two lists in parallel)

I will stick with own timer for sometime but the update is nice. Thank you

@spacepolice10 I working on the next major version and I planning to add "delay" option to scrollToIndex with other features