panic: interface conversion: fyne.Layout is nil, not *widget.ListLayout

[williambrode]

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

This panic happens intermittently when my app is starting. Unfortunately I only have a picture of the stacktrace right now:

The panic is here:

func (l *List) Resize(s fyne.Size) {
	l.BaseWidget.Resize(s)
	l.offsetUpdated(l.scroller.Offset)
	l.scroller.Content.(*fyne.Container).Layout.(*listLayout).updateList(true)   <<<<<<<
}

The layout is supposed to be set by CreateRenderer:

func (l *List) CreateRenderer() fyne.WidgetRenderer {
	...
	layout := &fyne.Container{}
	l.scroller = widget.NewVScroll(layout)
	layout.Layout = newListLayout(l)
	...
}

So it appears that Resize can be called before CreateRenderer - in which case I think we should probably just check that the Layout is not null in Resize() before trying to update it?

func (l *List) Resize(s fyne.Size) {
	l.BaseWidget.Resize(s)
	l.offsetUpdated(l.scroller.Offset)
        if l.scroller.Content.(*fyne.Container).Layout != nil {
                    l.scroller.Content.(*fyne.Container).Layout.(*listLayout).updateList(true)
        }
}

How to reproduce

Included code sample causes the panic

Screenshots

No response

Example code

myList := widget.NewList(func() int {return 0}, func() fyne.CanvasObject {return widget.NewButton("", func() {})}, func(lii widget.ListItemID, co fyne.CanvasObject) {})
	myList.Resize(myList.Size())

Fyne version

2.2.3

Go compiler version

1.19.1

Operating system

Windows

Operating system version

Windows 10

Additional Information

No response

[andydotxyz]

I think the crash varies based on the Fyne version. Can you see if this alternative fix helps?

index 51671ce6..6c4c71f7 100644
--- a/widget/list.go
+++ b/widget/list.go
@@ -111,6 +111,10 @@ func (l *List) scrollTo(id ListItemID) {
 // Resize is called when this list should change size. We refresh to ensure invisible items are drawn.
 func (l *List) Resize(s fyne.Size) {
        l.BaseWidget.Resize(s)
+       if l.scroller == nil {
+               return
+       }
+
        l.offsetUpdated(l.scroller.Offset)
        l.scroller.Content.(*fyne.Container).Layout.(*listLayout).updateList(true)
 }

[williambrode]

Ah sorry, I cut out our error handling code in the stack trace but should have showed you the panic message:

Its the Layout that is nil in my case. But its probably a race condition so perhaps we need to check both for nil.

[andydotxyz]

I think that in 2.2.x to 2.3.x the code changed so the fix I suggested does resolve the issue for our next release. Opening PR accordingly.

[Jacalz]

This was fixed a while back. Closing

[williambrode]

I can confirm this is still an issue on fyne 2.3.5 - is there reason to believe it was fixed after that point?

Panic backtrace:

fyne.io/fyne/v2@v2.3.5/widget/list.go in (*List).Resize at line 156
fyne.io/fyne/v2@v2.3.5/layout/maxlayout.go in (*maxLayout).Layout at line 22
fyne.io/fyne/v2@v2.3.5/container.go in (*Container).layout at line 195
fyne.io/fyne/v2@v2.3.5/container.go in NewContainerWithLayout at line 51
fyne.io/fyne/v2@v2.3.5/container/container.go in New at line 12
fyne.io/fyne/v2@v2.3.5/container/layouts.go in NewMax at line 91

In CreateRenderer we have:

l.scroller = widget.NewVScroll(layout)
layout.Layout = newListLayout(l)

So there is a time when scroller is not nil, but Layout is not set.

But in Resize we only check if scroller != nil before assuming Layout is populated:

       if l.scroller == nil {
   	return
   }

   l.offsetUpdated(l.scroller.Offset)
   l.scroller.Content.(*fyne.Container).Layout.(*listLayout).updateList(true)

[andydotxyz]

Please update to v2.4.0 and check the fix, the way list init was handled changed from 2.3 to 2.4

is there reason to believe it was fixed after that point?

Please try not to be sarcastic - we would not close the ticket if we didn't believe the fix had resolved the issue.

[williambrode]

I was not being sarcastic - I was asking if you thought it might be fixed in 2.4+, which you've confirmed it might be.

[Jacalz]

The issue was closed because #3453 was merged saying that it fixed the issue. If anything, the issue should be fixed with v2.4.0. v2.3.5 is no longer the latest version so testing with it doesn't help much honestly