1890848 - [toolbar redesign] The nav bar should automatically appear when closing the keyboard.

Status: RESOLVED FIXED

(Fenix :: Toolbar, task, P1)

Description

[Roger Yang [:royang]]

Attachment: screen-20240408-140248.mp4

Comment 2

[Chris Peterson [:cpeterson]]

Setting toolbar redesign's Beta experiment blockers to priority P2 until we finish fixing our Nightly blockers.

Comment 3

[Chris Peterson [:cpeterson]]

Nightly blocker

Comment 4

[Mike a [:mavduevskiy]]

likely gets fixed by 1898059

Comment 5

[Mike a [:mavduevskiy]]

Attachment: Bug 1890848 - Refactor isToolbarAtBottom into an extension function

The function is duplicated in Home and Browser fragments and being used to determine if the address bar is positioned at the bottom. Moving it into an extensions reduces code fragility, as well as allowing other components, not just fragments, to reliably check the address bar position.

Comment 6

[Mike a [:mavduevskiy]]

Attachment: Bug 1890848 – Show the navbar when keyboard is hidden

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b1bbdbf70ab0
Refactor isToolbarAtBottom into an extension function r=android-reviewers,gl
https://hg.mozilla.org/integration/autoland/rev/5b84e9134dc9
– Show the navbar when keyboard is hidden r=android-reviewers,gmalekpour

Comment 8

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/b1bbdbf70ab0
https://hg.mozilla.org/mozilla-central/rev/5b84e9134dc9

Comment 9

[Mike a [:mavduevskiy]]

found a use case missed:
opening a tab through tabs tray and closing keyboard

Comment 10

[Mike a [:mavduevskiy]]

Attachment: Bug 1890848 - part1, Show navbar after keyboard is dismissed

A mechanism that prevents the navbar from being drawn in case the home page is opened with intent to focus addressbar automatically (which cases glitching), was setting visibility to the compose view, but BottomToolbarContainerIntegration was managing visibility using the container. Using the container looks more appropriate.

Comment 11

[Mike a [:mavduevskiy]]

Attachment: Bug 1890848 - part2, Refactor BottomToolbarContainerView to restrict access to the compose view parameter

Restricting access to compose view, so that visibility of the container would be managed through container view only.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0937386f87e4
part1, Show navbar after keyboard is dismissed r=android-reviewers,tchoh
https://hg.mozilla.org/integration/autoland/rev/67d1ccd7b83d
part2, Refactor BottomToolbarContainerView to restrict access to the compose view parameter r=android-reviewers,skhan

Comment 13

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/0937386f87e4
https://hg.mozilla.org/mozilla-central/rev/67d1ccd7b83d

Comment 14

[Aarjav [:aarjav]]

Attachment: 1000067570.mp4

This bug reappeared. Attached video.

Comment 15

[Mike a [:mavduevskiy]]

hey, Aarjav!

What's the behaviour that you would expect in this case? The use case you recorded.

From engineering perspective, it works correctly and the issue lies in a different tech realm – it should be fixed here.

In short, it has to do with the way android OS is handling the hiding keyboard. When navigation in OS is set through gestures, not navigation bar, the hide keyboard button hides the keyboard but the focused element still holds the focus. You can see this behaviour across all android apps, except – ironically – Chrome. But other browsers I tested, Google app, gphotos and gmail treat hiding the keyboard just as hiding the keyboard, focused element retains focus.

And that's the bug you noticed – the keyboard is hidden, but the toolbar is still focused (you can see the cursor is still there), and it takes a second back gesture to actually close the toolbar in edit mode and go back to display mode.

The behaviour is different if you switch system navigation to button navigation. It will work as you expect.

Overriding system behaviour here isn't straightforward, but it's something we have as a todo thing.