Page scrolls up when typing (when being zoomed out in Safari)

[receter]

Steps to reproduce:

1. Open Demo (http://www.jacklmoore.com/autosize/) in Safari (15.2)
2. Zoom out one step using cmd -
3. Scroll down a little bit so there is room to scroll up
4. Type in the first Textarea, the page starts scrolling up while typing

Note: this only happens when zoomed out one step

[alehaa]

I can reproduce this in Safari 15.3.

[jackmoore]

Thanks for the reproduction steps. I don't have time to look into this right this moment, but it sounds like something that I probably won't be able to workaround and will have to list as a known issue. I don't think there is a good way for me to detect of the browser is zoomed in or not in order to opt-out of using autosize.

The way autosize does its height calculations is to remove the height from the textarea and measure how much overflow it has, then set it back to its previous height + overflow. I expect that approach is causing this problem. The alternative approach would be to have a hidden textarea element that mirrors all the input + styles + dimensions of the real textarea element that can be used for making calculations without affecting the document-flow, but that has a lot of problems too and would be an entirely different script.

I think these types of issues could be avoided if autosize wasn't expected to shrink when content is deleted. Trying to capture the shrinking of the textarea element is what's causing these reflow issues because there is no way to know that the textarea should be smaller without first making it smaller to see exactly how much (if any) overflow it would still have.

Sorry, I know you probably don't care about these implementation details, just trying to say that this might be an unfixable problem with this particular script unless you are willing to give up some functionality (shrinking).

[receter]

Thank you for your detailed explanation, maybe it is a Safari bug.

When I open the console in Safari (for a page that is zoomed out one step) and set:

> document.documentElement.scrollTop = 10
< 10

And then I read the same value:

> document.documentElement.scrollTop
< 9

[receter]

I filed a WebKit bug report https://bugs.webkit.org/show_bug.cgi?id=237225 let’s see what happens.

When I remove the lines there scrollTop is set, the issue seems to be gone. But I guess this is here for a reason.

// prevents scroll-position jumping
overflows.forEach(el => {
	el.node.scrollTop = el.scrollTop
});

if (docTop) {
	document.documentElement.scrollTop = docTop;
}

[jackmoore]

When I remove the lines there scrollTop is set, the issue seems to be gone

Thanks for the info.

But I guess this is here for a reason.

Yeah, it's like a bookmark to restore the scroll position of the page after calculations are done. When the height is removed from the textarea element it can change the height of the page which can lead to the scroll position not being in the same place once the textarea height is re-established. It's related to the problem I mentioned earlier about not having a good way of determining the actual height without clearing the existing height first. Sorry to drop the ball on responding.

That scroll position code would be unneeded if autosize was changed to not detect shrinkage (no need to clear existing height, just need to check if overflow exists in order to further expand height).