Entry without scrollable content prevents scrolling of outside scroller

[Jacalz]

Describe the bug:

An empty (or just not with enough content to scroll) will prevent the scrolling of an external scroller even though there is nothing to scroll within it.

To Reproduce:

Steps to reproduce the behavior:

1. Make the window large enough that it can be scrolled.
2. Move the mouse to be over the label.
3. Scroll and notice that it works as expected.
4. Move the mouse to be over the entry.
5. Scroll and notice that it does not scroll.

Screenshots:

Example code:

package main

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

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

	w.SetContent(container.NewScroll(
		container.NewVBox(
			widget.NewEntry(),
			widget.NewLabel("Scroll on me!"),
		),
	),
	)

	w.ShowAndRun()
}

Device (please complete the following information):

• OS: Linux
• Version: 5.10.12
• Go version: 1.15.7
• Fyne version: 2.0.0

[stuartmscott]

Agreed this is an issue, though it is not specific to Entry - any nested scrollers will encounter this problem where the inner scroller reaches its limit but cannot defer the scroll event to the outer scroller

[andydotxyz]

I think you would avoid it by specifying Entry.Wrapping = fyne.TextWrapNone

[andydotxyz]

I don't really think this is a blocking bug.
I'm even tempted to say it's not a bug, this is a (poor?) design.
Is this an enhancement?

I don't think we should change this behaviour under a bug fix release, it is a larger issues at work here that could result in bahaviour changes not intended.

[Jacalz]

Sure, maybe not a bug, but certainly very annoying. While the example gif above of course does not show it, this is making Sparta almost unusable when you try to scroll the form full of entry widgets.

I'd almost say that it is a blocker just because the entry widgets make the issue so much more noticeable.

[andydotxyz]

Turning off wrapping did not help?

[Jacalz]

Turning off wrapping did not help?

Haven’t tried yet. Just posting a reply from my phone.

[andydotxyz]

It won't fix it, I realised that the type of scroll is not checked - only the presence of a scroller.

I would propose that this is downgraded from blocker by adding something like

	objects := []fyne.CanvasObject{box, line, e.content}
	if e.Wrapping != fyne.TextWrapOff {
		e.scroll = widget.NewScroll(e.content)
		objects = []fyne.CanvasObject{box, line, e.scroll}
	}

This goes in Entry.CreateRenderer for now, it may need to be addressed in updateScrollDirections as well for a complete solution.

[andydotxyz]

The alternative would be to add some smarts to mouseScrolled in internal/driver/glfw/window.go (plus same in mobile).

	co, _, _ := w.findObjectAtPositionMatching(w.canvas, w.mousePos, func(object fyne.CanvasObject) bool {
		if s, ok := object.(*intWidget.Scroll); ok {
			return s.Direction != intWidget.ScrollNone
		}

		_, ok := object.(fyne.Scrollable)
		return ok
	})

Of course this puts a dependency back on widget, because the direction is not exposed through the Scrollable interface...

[andydotxyz]

The agreed workaround is on develop and release/v2.0.x