An overflow-y: visible !important; is fixing this on the textarea. @matmarex What do you think?

I can't reproduce the issue.

overflow-y: visible can not possibly fix it though, because you still have overflow-x: auto set elsewhere, so it is ignored:

https://www.w3.org/TR/css-overflow-3/#overflow-properties

Name:	'overflow-x', 'overflow-y'
…	…
Computed value:	as specified, except with 'visible' computing to 'auto' if one of 'overflow-x' or 'overflow-y' is not 'visible'

It sure does jump, in Chrome and Firefox. This is Chrome:

(Note also how at some point the scrollbar doesn't disappear – this happens when I have 112%-sized system font in Chrome, but that's another issue.)

It feels quite annoying.

I noticed how the comment input doesn't jump in DiscussionTools under the same circumstances. What did you guys do? Are you just making the input one line higher on every step, so the scrollbar doesn't have the chance to appear? (Is it because of this issue or for other purpose?)

Wow, I forgot about this task completely. And in fact I can reproduce now.

In T169335#8038235, @Jack_who_built_the_house wrote:

I noticed how the comment input doesn't jump in DiscussionTools under the same circumstances. What did you guys do?

I was surprised myself, it looks like we've done it in T267609 – we've just added overflow-y: hidden; to the textarea. This is only a viable option if there's no limit to the height of the autosized field (so you definitely never need the scrollbar), which is technically not possible in OOUI (which is probably why the fix isn't there) – we've used maxRows: 999 in our own code (eww).

Also I can still (inconsistently) reproduce the problem in DiscussionTools despite that – it's just a lot less apparent because the scrollbar doesn't appear, but the text does jump.

(All of the above only applies to DiscussionTools with the editing tools in source mode turned off – when they're turned on, the editor is a VE surface, which autosizes itself due to the normal behavior of contenteditable elements, and isn't affected by this bug at all.)

Are you just making the input one line higher on every step, so the scrollbar doesn't have the chance to appear? (Is it because of this issue or for other purpose?)

The bottom padding you're probably thinking of is unrelated, it was added because there's a button that can appear overlapping the editor (T300560).

If I add overflow-y: hidden; to a regular MultilineTextInputWidget, it doesn't, in fact, alleviate the problem of jumping text – it only hides the scrollbar.

The bottom padding you're probably thinking of is unrelated, it was added because there's a button that can appear overlapping the editor (T300560).

The fun thing here is that, while the change was unrelated, this padding together with overflow-y: hidden; prevents text from jumping.

With padding-bottom:

Without padding-bottom:

So, in summary, do I understand correctly that to fix this locally (if this isn't fixed globally shortly), the options are:

• either to set an overflow-y: hidden and padding-bottom to the textarea, and set maxRows: 999 or a higher value to the widget
• or to attach a resize handler increasing the height nearly by the height of a line:

this.commentInput.on('resize', () => {
  const saferHeight = parseFloat(this.commentInput.$input.css('height')) + lineHeight;
  this.commentInput.$input.css('height', saferHeight);
  this.commentInput.styleHeight = saferHeight;
});

? (For an input with 20px line-height padding-bottom: 20px was enough for both Chrome and Firefox and a 21px addition to the height in the second option.)

I think conceptually the first is better since the second resizes the element once again after a resize event is emitted, and it either needs to emit a second event and prevent itself from handling it, or this resize would be unhandlable.

And this is how autosizing behaves in last Firefox occasionally if you have the system font size other than 100% in Windows 11:

The height alternates between 87px and 86.8px.

This happens not with every form, with 1 in several. In case of other forms, this microjump happens when you add a 3rd line to the input (the form has rows="3"):