Widgets added to Overlay have incorrect Size until window Resize event occurs.

[Sponge96]

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

When adding a Widget to the Canvas().Overlays() without first setting its Size() to Canvas().Size() it is displayed with it's current Size() (Usually its MinSize()) instead of the size of the Canvas. Upon resizing the Window (Not via code) it is then resized to the full Canvas().Size() as you would have expected when it was initially added. The 'correct' behavior would be for the Widgets Layout() to be called with the Canvas.Size() when Canvas().Overlays().Add(widget) is called.

• Occurring on Linux/Windows (@andydotxyz was unable to reproduce on MacOS)
• Reproducible with provided widget/canvas objects (canvas.Rectangle, widget.Label, etc)
• Reproducible using a custom Widget with custom renderer (or provided widget.NewSimpleRenderer())
• Not occurring with provided widgets that handle their own interaction with the Canvas().Overlays() such as ModalPopup.

How to reproduce

1. Using the provided example code launch the application.
2. Press "Space" - This will add a Black Rectangle to the Canvas().Overlays(). It will be 100, 100 instead of spanning the full Canvas.
3. Resize the window by dragging the corner (or however your Display Manager handles resizing) - The Black Rectangle will now span the full Width/Height of the Canvas.

Screenshots

Using the example code provided, when you press "Space" it will add bar to the Canvas().Overlays() which in this case is a simple canvas.Rectangle. When this is added to the overlay it's using the current Size() value of 100, 100.

If you resize the window by dragging it out slightly, it updates to span the Width/Height of the full Canvas.

Example code

package main

import (
	"image/color"

	"fyne.io/fyne/v2"
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/canvas"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/widget"
)

type Foo struct {
	canvas fyne.Canvas
}

func main() {
	a := app.New()
	w := a.NewWindow("Test")

	foo := &Foo{
		canvas: w.Canvas(),
	}
	mainView := container.NewVBox(widget.NewLabel("SOME CONTENT"))

	w.SetContent(mainView)
	w.Canvas().SetOnTypedKey(foo.keyHandler)
	w.ShowAndRun()
}

func (f *Foo) keyHandler(e *fyne.KeyEvent) {
	switch e.Name {
	case fyne.KeySpace:
		bar := canvas.NewRectangle(color.Black)
		bar.Resize(fyne.NewSize(100, 100))
		f.canvas.Overlays().Add(bar)
	}
}

Fyne version

v2.5.2

Go compiler version

1.22.6

Operating system and version

NixOS

Additional Information

Reproducible on NixOS with both Hyprland and Gnome as well as Window11, with multiple different hardware setups.

Another method for viewing this behavior. This requires you to launch the application in debug mode go run -tags debug . This method will add a Label instead and you will see that it's bounding box is it's MinSize() when first added but after resizing the window the bounding box spans the Width/Height of the canvas the same as the Rectangle example.

package main

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

type Foo struct {
	canvas fyne.Canvas
}

func main() {
	a := app.New()
	w := a.NewWindow("Test")

	foo := &Foo{
		canvas: w.Canvas(),
	}
	mainView := container.NewVBox(widget.NewLabel("SOME CONTENT"))

	w.SetContent(mainView)
	w.Canvas().SetOnTypedKey(foo.keyHandler)
	w.ShowAndRun()
}

func (f *Foo) keyHandler(e *fyne.KeyEvent) {
	switch e.Name {
	case fyne.KeySpace:
		bar := widget.NewLabel("LABEL")
		f.canvas.Overlays().Add(bar)
	}
}

[steampoweredtaco]

Confirmed on my windows machine. It seems like the main reason is that the canvas object for the overlay isn't in the cache yet when the initial refreshes are called. So seems like a cache issue. It appears that maybe mobile driver actually will force the minsize but the gl driver doesn't?

@Sponge96 this is a workaround based on your code:

package main

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

type Foo struct {
	canvas fyne.Canvas
}

func main() {
	a := app.New()
	w := a.NewWindow("Test")

	foo := &Foo{
		canvas: w.Canvas(),
	}
	mainView := container.NewVBox(widget.NewLabel("SOME CONTENT"))

	w.SetContent(mainView)
	w.Canvas().SetOnTypedKey(NewKeyHandler(foo, w))
	w.ShowAndRun()
}
func NewKeyHandler(f *Foo, w fyne.Window) func(e *fyne.KeyEvent) {
	return func(e *fyne.KeyEvent) {
		switch e.Name {
		case fyne.KeySpace:
			bar := canvas.NewRectangle(color.Black)
			pos, size := w.Canvas().InteractiveArea()
			bar.Move(pos)
			bar.Resize(size)
			f.canvas.Overlays().Add(bar)
		}
	}

}

edit: sorry for the extra old test code that was in there before.

[Sharrnah]

Could be related.
It seems textareas inside Split containers are not always rendered or rendered in the correct size if switching between tabs that contain these.

Using Fyne v2.5.3 on windows 11.

In the screenshot, the text fields should fill both sides of the split part. (there is no vertical split between them)

Edit: Seems its only with widgets that are used on multiple tabs. Seems it does not correctly resize them when switchting between tabs like it did before the fyne update.

I added a Refresh() when switching tabs, which seems to have solved the issue.

[andydotxyz]

@Sharrnah this is not related - the ticket is explicitly a problem for overlays only.

With regards to your problem a widget should never be in two places at once. So something that is "on multiple tabs" should really be two similar widgets.

Remember that this toolkit is stateful - it remembers everything for you. Therefore the position of a widget is remembered and if you put it into multiple containers it won't know where it is supposed to be.

[Sharrnah]

@Sharrnah this is not related - the ticket is explicitly a problem for overlays only.

With regards to your problem a widget should never be in two places at once. So something that is "on multiple tabs" should really be two similar widgets.

Remember that this toolkit is stateful - it remembers everything for you. Therefore the position of a widget is remembered and if you put it into multiple containers it won't know where it is supposed to be.

I am aware of that, but the Widgets are always only shown once on screen, not at the same time. And it worked flawlessly before.
And it has a reason why i share the same widget, since i don't want to synchronize the widget content all the time.

If its unrelated i will create a new issue, since i am still the opnion that this is a bug.

[andydotxyz]

And it has a reason why i share the same widget, since i don't want to synchronize the widget content all the time.

A widget should not be in two places at the same time - it doesn't matter if they are shown or not.
If you truly want the same widget in two different containers then you should remove it from one parent and then add it to another. This action will cause caches / locations to be updated accordingly and there is no longer any ambiguity.

[Sharrnah]

Since my issue is not related, i say we continue this in my new opened issue that also has some additional information and demo code. :)