Support multiline text display in the Virtual Keyboard

[pazam-h2]

Adds support for displaying multi-line text in the Virtual Keyboard input field.

Since the current Virtual Keyboard input field was single-line, text containing new lines could appear as if the words were joined together. For example:
First line\nSecond line

was displayed as:
First lineSecond line

The Virtual Keyboard can now open in multi-line mode when requested by the caller. In this mode, line breaks are displayed as actual line breaks.

Details:

• Added an isMultiLineText argument to openVirtualKeyboard().
• Passed the multi-line mode into KeyboardRenderer.
• Used the existing multi-line support in TextInputField.
• Adjusted the input area height dynamically from 1 row up to 3 rows.
• Used text background shading for the multi-line input area.
• Moved the keyboard buttons down when the multi-line input area is used.
• Kept all single-line Virtual Keyboard usages explicit and unchanged.

Fixes #10755

Related to #8758 (not yet fixes it, since there's still no way to insert new lines in the virtual keyboard, but it's a big step toward it)

[ihhub]

Hi @pazam-h2 , I proposed another approach for the problem. Can you please check it?

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

[ihhub]

Hi @pazam-h2 , I left few more comments here. Can you please check them?

[ihhub]

Hi @pazam-h2 ,

Please fix this case:

[ihhub]

Also, we should allow to use Up and Down buttons to navigate through the text. Right now only Left and Right button (on keyboard) work.

[pazam-h2]

@ihhub -

Regarding the image you showed-

TextInputField handles multi-line rendering, but in this dialog the Virtual Keyboard still needs to limit which part of the full text is drawn inside the fixed multi-line input area. Otherwise, text beyond the visible area can be rendered over the keyboard buttons.

I’ll restore a fixed visible text view for the Virtual Keyboard multi-line mode, so only the visible 5 lines around the cursor are drawn.

Regarding the up/down navigation:

Agreed. I’ll add Up and Down handling for the Virtual Keyboard text cursor, so the cursor can move between lines in multi-line mode in addition to the existing Left and Right movement.

[Branikolog]

Hi, @pazam-h2
The issue mentioned by @ihhub is still valid:

Could you, please, check?

[ihhub]

Hi @pazam-h2 , can you please address given comments from @Branikolog ?

[pazam-h2]

@Branikolog -

Addressed the issue.

The previous implementation only limited lines separated by explicit newline characters, so long text that was automatically wrapped could still overflow the input area.

I changed the implementation to rely on the existing TextInputField/text layout logic for wrapped lines and added vertical scrolling so the cursor and current line remain inside the fixed multi-line input area. Up/Down navigation now also follows the actual rendered lines, including automatically wrapped ones.

I suggest checking it out, it feels very smooth now. IMO, the only thing still missing for a complete multi-line Virtual Keyboard experience is an Enter key for inserting new lines.

@ihhub -
Sorry for the delay, I was occupied with other things.

[ihhub]

Hi @pazam-h2 , I put few comments here. Can you please check them?

[Branikolog]

Hi, @pazam-h2 !
I've made a couple tests and here's what I've found:

2026-09-05.15-18-50.mp4

Could you, please try to fix this?

[pazam-h2]

@Branikolog -
Sure, fixed it.
The scrolled text is now properly clipped to the multi-line input area, so it no longer peeks outside the brown text field.

[Branikolog]

Hi, @pazam-h2 !

I tested this PR once again, and here are some observations.

First, since the input window is now taller, there is still a possibility that the whole text will not fit vertically. It would be great if this area supported scrolling, because currently the only way to navigate through the text above or below the visible area is by using the Up and Down arrow keys. This may not be available on devices with touch screens.

Also, the cursor positioning seems to work a bit incorrectly at the moment. When placing the cursor manually, the text area automatically shifts the text upwards, leaving the cursor at the very bottom. This is useful when returning to previous lines, but it does not work in the opposite direction when trying to move to the end of the text.

Currently, to see text below the visible area, it is possible to click slightly to the right of the last visible line, but this behavior is not obvious and may become inconvenient with long lines filled with text. Perhaps the text could be shifted in both directions when placing the cursor near the corresponding upper or lower areas of the input field. How do you think?

2026-09-13.15-41-27.mp4

I also noticed an inconsistency between the two input methods regarding the maximum text length.

In the virtual keyboard input window, text cannot be entered using the physical keyboard, but the Space key still works. If we continue entering text using the virtual keyboard, it is possible to exceed the maximum allowed text length from the previous text input window.

After that, the text cannot be edited in the original input window anymore — the only available action is deleting characters until the excess length is removed.

It would be great to have consistent behavior and the same text length limitations for both input methods.

2026-09-13.15-51-16.mp4

I am not sure whether all of these issues are directly related to this PR, but the text input behavior currently feels inconsistent and may need some additional adjustments.