Focus events cause multiline entry to change scroll position to show cursor

[nullst]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

If a multiline entry has enough text for a scrollbar to appear, whenever this entry gains or loses focus the widget automatically scrolls the text so that the cursor position is visible. Typically this behavior is very far from user's expectation. The entry should automatically scroll to the cursor position only when something happens at the cursor (e.g., user inputs something or changes the cursor position with arrow keys).

Example scenario: user has edited some part of the text in the multiline entry and wants to edit something below. User scrolls to see the location of the next planned edit. However, before clicking there, user does something with other widgets in the window (imagine clicking on the save icon, for example). At this moment, the entry scrolls back to the location of the first edit, to user's annoyance.

I have provided a toy example of this scenario below. However, the same issue can appear in other scenarios. For example, the scrolling to the cursor position also happens when the entry gains focus. This leads to very inconvenient behavior when user scrolls a currently unfocused multiline entry to find the place for a next edit, then clicks there expecting the cursor to jump to that position, but at this moment the entry scrolls back to the previous cursor position and the click lands at an unexpected position.

How to reproduce

1. Run the code fragment below. If necessary, shrink the window so that the text in the multiline entry on the right can be scrolled.
2. Put cursor somewhere in the first paragraph in the multiline entry.
3. Without changing the cursor position, scroll the text downwards (via mouse wheel or equivalent). It's easiest to see the bug effect when scrolled to the very end.
4. Click on the left-side entry.
5. Observe that the multiline entry has jumped back to the cursor position.

Screenshots

fyne-focus-bug-2025-12-03_16.07.15.webm

Example code

(This example is AI generated, but works OK)

package main

import (
	"fyne.io/fyne/v2"
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/widget"
)

func main() {
	myApp := app.New()
	myWindow := myApp.NewWindow("Fyne Bug Demo")
	myWindow.Resize(fyne.NewSize(800, 600))

	// Left side: single line text entry
	leftEntry := widget.NewEntry()
	leftEntry.SetPlaceHolder("Enter text here...")

	// Right side: multiline text entry
	rightEntry := widget.NewMultiLineEntry()
	rightEntry.SetText(generateFixedText())
	rightEntry.Wrapping = fyne.TextWrapWord

	// Create horizontal split container
	split := container.NewHSplit(
		leftEntry,
		rightEntry,
	)
	split.Offset = 0.3 // 30% left, 70% right

	myWindow.SetContent(split)
	myWindow.ShowAndRun()
}

func rotText(s string, n int) string {
	runes := []rune(s)
	for i, r := range runes {
		switch {
		case r >= 'A' && r <= 'Z':
			runes[i] = 'A' + (r-'A'+rune(n))%26
		case r >= 'a' && r <= 'z':
			runes[i] = 'a' + (r-'a'+rune(n))%26
		}
	}
	return string(runes)
}

func generateFixedText() string {
	fragment := "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\n" +
		"Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure " +
		"dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.\n\n"

	text := fragment
	text += rotText(fragment, 4)
	text += rotText(fragment, 8)
	text += rotText(fragment, 12)
	text += rotText(fragment, 16)

	return text
}

Fyne version

2.7.1

Go compiler version

1.19

Operating system and version

Pop OS 22.04

Additional Information

No response

[andydotxyz]

Just to check - from reading the description is it the case that this is actually about the Unfocus event (from the Multiline entry perspective)

[nullst]

It happens for both focus in and focus out events. It is more obvious that the behavior is unwanted in the unfocusing case, that's why I presented it in the video example, but both situations are problematic.

You can use the same example to see undesirable behavior in the focus in case:

1. Run the minimal example code. Shrink the window so that you can scroll the right-hand side entry.
2. Click on the small entry on the left so that it becomes focused.
3. Scroll the contents of the right-hand side entry far below.
4. Now click somewhere in the text on the right-hand side.

You would expect the cursor to be placed at the position where you clicked, but instead the multiline entry changes the scroll position to the very top (my guess: default cursor position is considered to be at the start, and the scroll goes to the cursor position) and the click is registered only after the window has scrolled.

Here's this scenario in action:

fyne-focus-bug2-2025-12-04_00.13.21.webm

[andydotxyz]

Thanks for the clarification. It seems like there may be two separate issues here:

1. when tapping/focusing away from an Entry widget the scroll and cursor should not move.
2. when tapping into an Entry the cursor should appear under the mouse even if it is scrolled. (Though from a keyboard focus in perhaps not, should likely go to cursor where it was left...)

Correct me if I am wrong - these could be addressed together but actually are separate.

[nullst]

I'm almost certain that those are the same issue: multiline entry changes the scroll position to show cursor whenever some kind of a focus event occurs (either focus in or focus out). Note that you can also trigger the second scenario by pressing tab key to switch the focus to the multiline entry. (I would argue that the automatic scrolling should not happen even in this case until user does something related to the actual cursor position).