[Android] Typing into an Entry field will resize the layout which cannot be restored

[Maverobot]

Describe the bug:

When typing into an "Entry" field, some widgets will be repositioned above the pop-up keyboard due to layout resizing. After the keyboard disappears, the resized layout is not restored. I have similar issues in another app which I am writing.

To Reproduce:

Steps to reproduce the behaviour:

1. Install fyne_demo on an android device
2. Open the app fyne_demo
3. Click Data Binding
4. Click the Entry field 0.200000 and change it to any value e.g. 1.2
5. See the Append button moved above the keyboard and will stay there after the keyboard hides.

Screenshots:

A short video.

Device (please complete the following information):

• OS: Android
• Version: 11
• Go version: 1.16.6
• Fyne version: 1f05de7
• Keyboard: Gboard
• Device: Pixel3a

[andydotxyz]

See the Append button moved above the keyboard and will stay there after the keyboard hides.

The video did not show this part... do you mean that the Append button disappears off the bottom of the screen, or that it will re-appear once the keyboard hides?

I cannot think why this button is moving as we don't currently move layouts to accommodate keyboard (though we do need to).

[Maverobot]

Thanks for the quick reply. I did not have a clear mind last night. :) Recreated the gif and updated it in the description as well:

http://imgur.com/a/tpvqmEA

[andydotxyz]

This is very strange indeed. I cannot replicate it on my Android devices.
Can you please provide more information about the Android configuration, keyboard installed etc.

[Maverobot]

It is weird indeed. Description updated. Let me know if you need more information.

[andydotxyz]

I think this will be resolved by #566 in the "E" release planned. Marking as duplicate.

[hkparker]

I have noticed in android, with an entry that is bound to the bottom of the screen via a border layout, it does not "pop up" to the new bottom of the screen when the keyboard appears. The layout is like:

content := container.NewVScroll(container.NewVBox())
entry := container.NewMax(widget.NewEntry())

container.New(
    layout.NewBorderLayout(nil, entry, nil, nil),
    entry,
    content,
)

I don't recall why I wrapped the entry in a max container tbh, but I don't think that's relevant to the behavior I'm describing.

I would expect the VScroll to shrink, and the new bottom of the border layout to be just above the keyboard, but this doesn't happen for me. I assume this is going to be addressed in the same mobile keyboard changes that are going into 2.5, so I'm planning on just waiting to test that when it's ready, but I wanted to share this in case it's unexpected / new.

[andydotxyz]

A Max with a single item is a no-op btw, so it could be removed.

The behaviour that you describe is now landed on develop branch and will be default in 2.5 - I should have closed this issue already :)

[hkparker]

Ah thanks, this was some code from my early fyne-using days. Looks like I was using it to unnecessarily re-type some widgets into containers, funny thing to come across now.

Great to hear, looking forward to the next release!

[hkparker]

Alright I got to building my app on develop and trying out this new behavior in android.

It worked, with two caveats:

• performance is pretty rough. I think this is just Android apps are lagging when enter text and scrolling #1062 but waiting for the keyboard to appear, then waiting for the entry to re-appear above it was not responsive. Entering text was pretty laggy too, seems like this is a known bug though.

• My scroll was scrolled all the way to the bottom, but when the keyboard appeared, the position of the scroll didn't change, such that the wigets in the scroll remained where they were in absolute position on the screen and I was no longer scrolled to the bottom. I'm not sure what behavior you intend here. For my use case, it would be good to remain scrolled all the way down after the keyboard is opened, pushing everything else "up", but I can do that myself with a manual call to ScrollToBottom if I can detect when the keyboard is opened via some sort of callback.

[andydotxyz]

To your second point we were going to add "ScrollItemVisible" or similar, but I don't think it was added yet...

[hkparker]

Oh, what's this? It's not clear to me what this would do in this context. It's a bit tricky I expect, but my ideal situation would be for the scroll to ascend the height of the keyboard when the keyboard is displayed, then return down when it is hidden (regardless of if the scroll was at the bottom when the keyboard was popped up).

This is all pretty specific to an entry that is bound to the bottom with a scroll above it, so if this takes a little extra work within the API that's not surprising to me. In order to do this with the API I'd need some way to hook into before and after the keyboard was present on screen (perhaps before and after the entry was focused), so that I could determine the difference in size of the scroll and adjust the position accordingly. As far as I can tell this isn't possible right now.

[andydotxyz]

I think the events available should be sufficient - the FocusGained and FocusLost on Entry should indicate if the keyboard is up or down. A very slight delay may be required but should not cause any issue visually.

[hkparker]

I was thinking I was going to need to run something immediately before and after the keyboard appeared, in order to tell how much the size of the scroll changed, but actually since this only matters on mobile, and the size of the window never changes on mobile, I should be able to do something like:

1. check the height of the scroll when I first display it and save that somewhere
2. after FocusGained, check the new height of the scroll and save the difference somewhere, then scroll down by the difference in height
3. after FocusLost, scroll up by that same difference, unless we're already scrolled to the bottom

I'll give this a try relatively soon.

It occurs to me now that multi-line entry growth also has this behavior, when an entry pinned at the bottom expands it occludes the scroll content. I'll try to apply a similar approach there.

[andydotxyz]

This probably relates to #3029

[hkparker]

Following up here, I implemented a FocusGained/FocusLost handler in my custom entry, and even just calling ScrollToBottom on my scroll did nothing after focus was gained on mobile (keyboard sill occluded stuff), so this is going to be a little more tricky than I originally thought. Using v2.5.0-rc1

[andydotxyz]

Perhaps worth opening a new issue to discuss that, the original issue is resolved in the release candidate.