1821706 - Keyboard animation improvements

Status: RESOLVED FIXED

(Fenix :: Homepage, defect, P2)

Description

[Joe M [:jmahon]]

Attachment: Android-Keyboard-Up.mp4

Keyboard animation improvements:

Originally taken from here

• When the keyboard raises from a website, we see all the jank of the homepage as it appears + the odd toolbar animation - see "Android-Keyboard-Up.mp4" video. First the toolbar state begins to change, then it duplicates with the previous version appearing in the final position. The bottom toolbar seems to move into place and then finally the keyboard animates in.

  • JM/GL notes: "Implementation ideas: hide placeholder search bar faster (e.g., before launching the search navigation fragment)? Or, lock the placeholder search bar behind the keyboard so it doesn't animate into the middle of the screen at all?

• When the keyboard drops, we get the odd toolbar animation in reverse - see "Android-Keyboard-Down.mp4" video.

  • JM/GL notes: "Inverse of the above - show the placeholder search bar later (or, leave it locked at bottom behind keyboard)"

Comment 1

[Joe M [:jmahon]]

Attachment: Android-Keyboard-Down.mp4

Comment 2

[Chris Peterson [:cpeterson]]

Tasks should have Severity N/A.

Comment 3

[Jonathan Almeida [:jonalmeida]]

(In reply to Joe M [:jmahon] from comment #0)

• JM/GL notes: "Implementation ideas: hide placeholder search bar faster (e.g., before launching the search navigation fragment)? Or, lock the placeholder search bar behind the keyboard so it doesn't animate into the middle of the screen at all?

Consider using the WindowInsetsAnimationCompat library to solve this for API 11+. I don't think there is any better way to solve this problem in Android today without it being a weird hack.

Comment 4

[Matt Tighe [:matt-tighe]]

I'm curious if we really need to be showing the homescreen when the toolbar is interacted with during browser sessions. Is there a reason that we don't just bring up the keyboard over the open tab?

Comment 5

[Joe M [:jmahon]]

:matt-tighe I think that's a pretty reasonable question - the switch between the current page & the new tab page when the keyboard pops up definitely feels a bit janky, IMO. Though, on the other hand, if you've activated the URL bar, it probably means you're done looking at the current page, so showing the user their homepage shortcuts is perhaps more convenient than having to open a new tab to access it.

I believe I've heard some past musings about going directly to the Search & Suggest results, but IIRC suggest doesn't have anything to offer until you start typing something in - so that change would require a bit more thought.

But all of that is a bit separate from this ticket, anyway (this is purely about the jank in the keyboard opening or closing) - if you want to open a bug for that as a way to make sure the idea doesn't get lost, I'd recommend doing so & attaching it as a blocker of "homepage-nitpicks-nonjuno" (same metabug this one is attached to).

Comment 6

[Alexandru Putanu [:aputanu]]

I implemented the suggestions from Joe and GL but by hiding the display toolbar before the showing the keyboard, we are left with a few frames of no visible toolbar (see video). I couldn't find any method of making the transition from display to edit mode more fluid.

Using WindowInsetsAnimationCompat callback for the toolbar doesn't solve the toolbar duplication problem, however we can obtain a smoother transition by hiding the display toolbar when the keyboard animation starts (see video), but we should keep in mind this solution works only for Android 11+ devices.

I think we should make a decision between

• allowing the toolbar duplication to exist
• compromise by hiding the toolbar (and have a few frames with no toolbar on screen)
• fixing this issue for Android 11+ devices only

Comment 7

[Alexandru Putanu [:aputanu]]

@Joe, how should we proceed with this ticket?

Comment 8

[Joe M [:jmahon]]

Oof, lost this needinfo, sorry for the delayed response!

If the change that you made and demonstrated here only works for Android 11+ devices, that's perfectly fine with me - as long as it doesn't add too much tech debt in the process.

Comment 9

[Alexandru Putanu [:aputanu]]

Eng note: I used this documentation page to provide the recording. We can use this to fix the keyboard animation for Android 11+ devices.

Comment 10

[Roger Yang [:royang]]

After some investigation into why this occurs, I suspect that this is just performance related. Currently our focus call on the toolbar gets call 4 times and each time we request focus and also ask for showing the keyboard. I think by removing those we will see some improvement without resorting to complicated animation fix.

Comment 11

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1821706 - Allow Android OS to decide when to show the keyboard for edit toolbar (#4840)

Comment 12

[BMO Github Automation]

Authored by https://github.com/rocketsroger
https://github.com/mozilla-mobile/firefox-android/commit/8f19821da654a2c71c5360e1ef72d4f3d4daf343
[main] Bug 1821706 - Allow Android OS to decide when to show the keyboard for edit toolbar

Comment 13

[Jonathan Almeida [:jonalmeida]]

royang, should we request QA verification for this user-facing change across a range of devices?

Comment 14

[Roger Yang [:royang]]

Good idea. Thanks

Comment 15

[Lorand Janos]

Verified on the latest Nightly build (123.0a1 from 2024-01-09).

Tested the keyboard rise and drop by filming the actions with slow motion to detect the mentioned behaviors.
Tested with the toolbar on the bottom and on top.
There were no issues.

Devices used:

• Samsung Galaxy S23 Ultra (Android 14).
• Google Pixel 7 (Android 14).
• Samsung Galaxy Tab A7 (Android 13 - Tablet).
• Vivo Y22S (Android 12).
• Xiaomi Mi11 Lite (Android 11).

Marking the ticket as verified on 123.

Comment 16

[Verdi [:verdi] Best to slack me]

Attachment: keyboard-123.mp4

I don't believe this is fixed. I can still reproduce the problem with Firefox 123 on my Samsung S9. I've attached a video of the keyboard going up but similar things happen when it lowers.

Comment 17

[Roger Yang [:royang]]

Thanks. This is probably (not sure) because of the performance of S9. This animation is done by Android OS and our toolbar design requires a lot of operations when redrawing. Since we're redesigning the toolbar experience, I've created an issue in the toolbar redesign epics to investigate this. https://bugzilla.mozilla.org/show_bug.cgi?id=1884393. I don't think there's more we can do here without changing how the toolbar works fundamentally.

Comment 18

[Jonathan Almeida [:jonalmeida]]

Roger, based on comment 16 and comment 17, can we revert this patch? It's causing a regression in bug 1875111 that is giving us negative user reviews and the workaround I've posted is also not good enough.

Comment 19

[Roger Yang [:royang]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #18)

Roger, based on comment 16 and comment 17, can we revert this patch? It's causing a regression in bug 1875111 that is giving us negative user reviews and the workaround I've posted is also not good enough.

I don't think we should be reverting this change since the show keyboard call was originally a hack because we don't understand why it doesn't show in fireTV. I think the better solution is to add showKeyboard() after the requestFocus() call and create an issue in Focus to figure out why we can't work without this call.

if you like I can put up a fix for Focus and also create the follow up Focus issue to track the investigation.

Comment 20

[Roger Yang [:royang]]

To be clear, the reason is the focus() is called multiple times, so I think the current implementation that will only call requestFocus() when !hasFocus() is the right solution.