Canvas.Focus() before window visible causes application to crash

[ababo]

Here is a part of the related stack trace:

2021/02/02 11:36:42 panic was raised: runtime error: invalid memory address or nil pointer dereference, stack: goroutine 27 [running]:
panic(0x46fac20, 0x536b050)
	/usr/local/Cellar/go/1.14.1/libexec/src/runtime/panic.go:967 +0x166
fyne.io/fyne/v2/internal/app.(*FocusManager).Focus(0x0, 0x4c62cc0, 0xc0007f2900, 0x0)
	/Users/ababo/go/pkg/mod/fyne.io/fyne/v2@v2.0.0/internal/app/focus_manager.go:25 +0x4f
fyne.io/fyne/v2/internal/driver/glfw.(*glCanvas).Focus(0xc0002a8100, 0x4c62cc0, 0xc0007f2900)
	/Users/ababo/go/pkg/mod/fyne.io/fyne/v2@v2.0.0/internal/driver/glfw/canvas.go:88 +0x1a8

This happens when trying to focus on widget.Entry or a custom control based on widget.List.

Platform: OS X 11.1
Go version: go1.14.1 darwin/amd64
Fyne version: v2.0.0

[andydotxyz]

It looks like the FocusManager is nil somehow.
Please can you share the code as there is not enough information here.

[ababo]

func createUserpassLoginPageContent(cg *util.CancelGroup,
	data *pageData, finished chan<- *pageError) fyne.CanvasObject {
	...	
	username := widget.NewEntry()
	...
	form := fyne.NewContainerWithLayout(layout.NewGridWrapLayout(formSize),
		widget.NewForm(
			widget.NewFormItem("Username", username),
			widget.NewFormItem("Password", password),
		),
	)

	control := fynecont.NewHBox(
		fynex.NewHorizontalMargin(loginPageSubmitMargin),
		fynecont.NewVBox(
			submit,
			progress.CanvasObject(),
		),
	)

	data.container.Canvas().Focus(username) <--- This line causes the crash.
	username.DoubleTapped(nil)

	return fynecont.NewVBox(
		newPageTitle(loginTitle),
		newRichText(loginText),
		fynex.NewVerticalMargin(loginPageFormMargin),
		fynecont.NewHBox(
			fynex.NewHorizontalMargin(loginPageFormMargin),
			fynecont.NewVBox(
				form,
				control,
			),
		),
		loggedInIndicator,
	)
}

[andydotxyz]

Ah. I see. I think this is caused because you are focusing an element that is not in the canvas (yet).
You raise an interesting point though, how do we handle the case where developers want to focus something they just created.

[ababo]

This worked before v2.0.0.

[AlbinoGeek]

I thought this was just me, haha.

[andydotxyz]

This worked before v2.0.0.

Ah, this would have been useful information for the initial bug report, but thanks.
If the crash is new, did it actually do what was expected in 1.4? I can't quite figure out how it could have worked so keen for more info.

[andydotxyz]

We are fixing the crash but returning to the 2.0 behaviour whereby an object must be in the tree before you can focus it.

[ababo]

The problem starts when you develop code that return a complex canvas object that presumes focusing. The returned object isn't aware when it will be attached to the canvas tree. This constraint will frequently force developers to add deferred focusing which will lead to fragile code.

[andydotxyz]

I agree that there are some areas that are going to need work.
Perhaps we can open a feature request for "request future focus" - this way the element could get focus when it is added.
That will be safe whereas doing it the way I had in the original PR is unsafe.

No object should assume it has focus - it will be informed when it has gained the window focus.

[andydotxyz]

On develop and will be in 2.0.1 release