Auto-resize changes pageOffsetY in Chrome when textarea is near bottom of window

[LBBO]

Describe the bug

When a b-form-textarea with more lines than it's rows attribute is edited, it can cause the window to scroll upwards. To me, it looks like this happens because the textarea shrinks in height due to height being set to auto in the on-change handler in form-textarea.js:176. If the window's bottom is now higher than the screen's bottom, the browser automatically scrools upwards to fill the empty space. Now, the textarea is reset in it's height, but the new scroll position is already set and doesn't change back.

Please note that I have only observed this bug in Chrome and could not reproduce it in Firefox.

Steps to reproduce the bug

1. Create a b-form-textarea and fill it with so many lines, that rows <= # lines <= max-rows. The textarea must overflow one of it's parents and cause a scroll bar.
2. Scroll to the very bottom of the overflowed parent.
3. Edit the textarea. The parent should now have scrolled up.

Expected behavior

The scrolling position should not change whenever editing a textarea, unless it is to display a new line that was added that would have otherwise been off-screen.

Versions

Libraries:
(See CodeSandbox below)

• BootstrapVue: 2.16.0
• Bootstrap: 4..5.2
• Vue: 2.6.0

Environment:

• Device: PC
• OS: Windows 10
• Browser: Chrome (works in Firefox!)
• Version: 84.0.4147.135

Demo link

See this CodeSandbox. Make sure to follow the steps above to observe the issue.

Additional context

I came across this bug in vabene1111/recipes and opened an issue there already. That issue contains a GIF showing the behavior in the app that might be helpful in case my description wasn't understandable enough.

[Hiws]

I just found an issue with the collapse component in Chrome as well, that has to do with the window scrolling.
I have a feeling this might be a new bug or "feature" in chrome, that's affecting components which compute height, and it's causing the parent to scroll.

https://bootstrap-vue.org/docs/components/collapse#accordion-support
If you open a collapse under the currently opened collapse, the window will scroll slightly. Probably the height of the collapse that was either closed or opened.

This does not happen if you open a collapse above the currently opened collapse, or simply open/close the same collapse.

[LBBO]

Wow, that's interesting! I think it might be related to the focus somehow. At least, the behavior doesn't occur when I trigger clicks via JS:

There might be other significant differences between clicking via mouse or via code, but this makes the most sense to me: the element which is in focus stays put while everything else moves. It actually kind of makes sense: the focussed element is probably most important to the user right now, so it probably shouldn't move around (or even off) the screen.

Btw: I checked and clicking on the buttons does focus on them, while calling button.click() does not.

[LBBO]

If the collapsing-issue actually is related to the focussed element being kept where it is, it would be a separate issue, though. I just checked the CodeSandbox and the container scrolls while the textarea is in focus, thus not keeping it where it is.

I also have to say that I've encountered similar issues before (where the body shrinks and then grows back to its original height but without restoring the scrolling position).

[LBBO]

Yup, the focus seems to be the issue here. Running

document.querySelectorAll('button.btn.btn-info.btn-block')
  .forEach(button => button.addEventListener('focus', () => button.blur(), {passive: true}))

in the console before clicking on the collapsibles fixes the issue for me.

[Hiws]

It might be a separate issue, but seemed oddly similar to your issue with the textarea.
Especially given both are (to my knowledge) issues in a newer version of chrome, and has to do with scrolling + height changing.

I'll continue to do some research.
Thanks for the research and finding the focus point, that's certainly interesting behavior.

[Hiws]

Looks like you were correct about it being a separate issue.
I've opened another issue to track it: #5715
Thanks for helping out 👍

[jacobmllr95]

I can't confirm this behavior on neither Chrome 84, Firefox or Safari on macOS.

[LBBO]

Is there anything for me to do to help you out with this?

[jacobmllr95]

@LBBO The question is if it is just a Chrome 84 bug on Windows or if it is something we have to work around.
Can you confirm that this issue still exists in Chrome 85 or the new Chromium base Edge browser?

[LBBO]

Yep, the bug still exists in Chrome 85.0.4183.102 (Official Build, 64-bit, same device and OS as before). The new Chromium based Edge isn't installed on my machine yet and I'd rather keep it that way for easier testing, but I could set up a VM and test it there, if you'd like.

[jacobmllr95]

@LBBO That would be awesome. The bug does not exist on Firefox and the "old" Edge?

It would also be helpful for me if you could do a short screen-capture of reproducing the bug in the CodeSanbox and Chrome.
I'am still not 100% sure if I followed your steps correctly.

[LBBO]

Sure thing! I couldn't reproduce it on Firefox and I haven't tested the old Edge yet. The testing will take me a few days though since I'm running out of time for this weekend.

As for the screen-capture: I added one to the issue I mentioned up top. Not a CodeSandbox, but it might help anyway. IIRC, max-rows is set to something like 2 or 4 in that application.

[Hiws]

I've just tested it in Firefox 79 & 80.0.1. Chrome 85 and Chromium Edge 85.
It appears to be an issue on all of them. However, i remember testing it in Firefox when the issue was made and didn't experience any issues then. However it might've been an old version since i rarely use Firefox.

The screencap below is in Firefox.

That's atleast the case if i understand the issue correctly.

[LBBO]

@Hiws Yeah, that's exactly what the issue is. One consequence, for example, is that you can't edit the bottom lines of a text area when it's too close to the end of body.

Thanks for taking care of the testing! If there's anything else I can do, just let me know

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[LBBO]

Has anything happened in regard to this? If not, is there anything I can do to help?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

[bobvandevijver]

For anyone finding this, this is still relevant with Edge 99.

Edit (25-01-2023): I worked around this issue by adding an observer that resizes a div wrapping the textarea based on the height inside. This does not pick up the auto height change that is being set shortly and therefor prevents the unexpected page scroll to be triggered.