1818624 - Persist the keyboard when switching to and from Private Browsing Mode

Status: NEW

(Fenix :: Homepage, defect, P3)

Description

[Gabriel Luong [:gl] (ΦωΦ)]

If the keyboard is up and you switch to or from Private Browsing mode, the keyboard lowers and then raises again.

This was raised in https://docs.google.com/document/d/1TY_7htyZs5g3Z90waSV8mLhunAF7qjxZC89Ng9ZdWnM/edit#

Comment 1

[Matt Tighe [:matt-tighe]]

Unfortunately, I don't think we can solve this problem without fundamentally restructuring our view hierarchy or, at minimum, introducing additional jank in how the toolbar changes states. I will go into deeper technical details below, but it would be my recommendation to revisit this as we convert to Compose or abandon the idea entirely. Any solution here seems likely to be a relatively large body of work with the risk of introducing latent bugs, increasing jank, and making the components involved more brittle to future changes.

PBB and PBM are private browsing mode button and mode, respectively.

Technical details:
This issue fundamentally stems from the following problems:

1. When the private mode button is clicked, we recreate the Home Activity and therefore all its child views in order to completely retheme the app. It seems like on my personal phone it is possible to force the keyboard to remain open across this configuration change, but this behavior can't be replicated on an emulator. I worry that this means the only possible solution would not be guaranteed to work correctly, especially on slower devices.
2. There does not seem to be a deterministic way to check whether the keyboard is currently open during view changes, because it is not guaranteed that we can execute a check before the Android system hides the keyboard during focus changes and click events. This introduces difficult in knowing whether to try and keep the keyboard open across the PBM switch.
3. We can only force the keyboard open from views that have editable text, which means the view must be focusable and focusableInTouchMode. While the search bar is not being interacted with, we intentionally make the toolbar TextView in the HomeFragment not focusable so that we can switch it to our custom BrowserToolbar when the SearchDialogFragment is inflated.
4. While the toolbar is editable and the keyboard is raised, these views are attached to the SearchDialogFragment. This means there are now (at least) 3 large view hierarchy inflated before the keyboard is set to be raised again after activity recreation - the HomeActivity, HomeFragment, and then finally the SearchDialogFragment.
5. The SearchDialogFragment displays an invisible window over the home screen while the toolbar is empty but editable. As soon as key presses are entered, this invisible window becomes visible and starts displaying search suggestions. While invisible, touch events are captured and delegated to the HomeFragment. We intentionally close the keyboard when delegating these events, because it means that search for be dismissed in every case except for clicking the PBB.

So basically, any solution would need to do the following:

1. Remove intentional keyboard hiding from SearchDialogFragment during PBB clicks
2. Discover deterministic way to check if keyboard was already open
3. Communicate open keyboard state to HomeFragment
4. Persist previously open keyboard state across activity recreation
5. Force keyboard to remain open during view inflation from HomeFragment in hacky way that might not even work on many devices

Comment 2

[Joe M [:jmahon]]

Thanks for the run-down, Matt, and for looking into this so thoroughly.

:verdi, at this point, we have to consider cost/benefit against other work:

• seems like the work needed for this would be more challenging than we had hoped (e.g., on the level of completely changing how we approach launching PBM - which is likely not advisable for the sake of this single task)
• should we consider alternative UX solutions? e.g. would it be better to have the keyboard dismiss and STAY dismissed, rather than popping back up? If so: feel free to reconnect with Matt about potential side-steps to the problem here
• do you think the perceived jank of this issue would be adequately reduced with the fix from bug 1821706, which would at least make the keyboard animations less jarring? If so, let me know and I can try to accelerate that one - though I'm not sure it'll make it into v114 for Juno, at this point.

Let us know what you think!

Comment 3

[Verdi [:verdi] Best to slack me]

should we consider alternative UX solutions? e.g. would it be better to have the keyboard dismiss and STAY dismissed, rather than popping back >up?

In this case we definitely want it to end in the up position.

do you think the perceived jank of this issue would be adequately reduced with the fix from bug 1821706, which would at least make the keyboard >animations less jarring? If so, let me know and I can try to accelerate that one - though I'm not sure it'll make it into v114 for Juno, at this point.

I don't think that will help this issue much. But bug 1821706 is generally more important than this issue because it affects every user. If we can work on that we should.