Open Bug 1909746 Opened 3 months ago Updated 2 days ago

[Toolbar Redesign] The saved login panels that appear because of feature access should appear above the toolbar irrespective of top/bottom placement of toolbar.

Categories

(Fenix :: Toolbar, task, P3)

All
Android
task

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: aarjav, Assigned: petru)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxdroid][group3][toolbar-redesign-release-blocker])

Attachments

(6 files)

Steps to reproduce

  1. Go to a website that requires a sign in
  2. Click on the username/password fields.

Expected behavior

  • The saved passwords panel should always be above the bottom-placed toolbar. An example is shown in the Figma link below.

Actual behavior

  • The saved passwords panel is placed below the toolbar.
  • This makes the passwords panel less contextual.

Device information

  • Firefox version: Nightly
  • Android device model: Pixel 6
  • Android OS version: Latest

Any additional information?

Figma Link: https://www.figma.com/design/8fsCvtnweBkWGZ9NfL907l/Toolbar-Redesign?node-id=17891-293506&t=ur7cBuPjAOXTzif6-4

Severity: -- → N/A
Priority: -- → P3
See Also: → 1910409
Attached image image.png

@AArjav What's the relation with other dialogs that now appear on top of the toolbar?

  • start download
  • download complete

Also the find in page bar which now replaces the toolbar.
Which should appear on top?

Also, I see that when the login select bar is expanded the toolbar should be hidden.
Would the other dialogs will remain shown?

Screenshot added for how the current UI.

Flags: needinfo?(apandya)
  • The download panels (start + complete) should continue to be shown over the nav bar.
  • The find in page should continue to replace the toolbar.
  • As we either override or replace the toolbar for the above features, the same behavior of expanded panel will not be seen.
Flags: needinfo?(apandya)
Assignee: nobody → petru
Status: NEW → ASSIGNED
Whiteboard: [fxdroid][group3]

Checked with Aarjav and the recommended way to avoid the conflict between the downloads panels and the logins ones is:

  • when the keyboard is shown
    • show the logins panels above the toolbar - they are needed for the autofill scenario that the user is in
    • hide the downloads panel - it's rather an inconvenience for the autofill scenario
  • when the keyboard is hidden
    • hide the logins panels - they are not immediately needed for an autofill scenario
    • show the downloads panel - as part of the normal browsing UX.

Working on this and trying to use the keyboard status as a way to know when to I see some edgecases which I think prevents us from reliably using this to disambiguate when to hide the downloads panels:

  • when the user is interacting with the expanded logins bar - the keyboard is closed but we still need to show the logins bars and not downloads
  • when using external keyboard a software one would not be shown on the screen.

We can though use the visibility of the logins bars to know when to hide other panels.

We had two interfaces - SelectablePromptView and PasswordPromptView with very
similar functionality.
Combined the same behavior and extracted the differences into new interfaces with a
more clearer scope.
This is a building block for easily adding more functionality later.

Looked into potential approaches to avoid the conflict with the download dialogs.
We could work more to ensure that when download panels appears they should hide these panels
And when these logins panels appear they should hide the download panels
And while one is shown don't hide the other
But this should mean that if a download is finished while the user interacts with logins we should remember to show again the finished downloads after the logins interaction is finished.
This all means brittle code and complexity that I'd prefer to avoid if we know that the download panels will soon be updated.
So waiting to merge up until after that.

Whiteboard: [fxdroid][group3] → [fxdroid][group3][toolbar-redesign-release-blocker]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: