[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)
Tracking
(Not tracked)
People
(Reporter: aarjav, Assigned: petru)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxdroid][group3][toolbar-redesign-release-blocker])
Attachments
(6 files)
Steps to reproduce
- Go to a website that requires a sign in
- 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?
Updated•3 months ago
|
Assignee | ||
Comment 1•29 days ago
•
|
||
@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.
Reporter | ||
Comment 2•29 days ago
|
||
- 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.
Assignee | ||
Updated•28 days ago
|
Updated•23 days ago
|
Updated•23 days ago
|
Assignee | ||
Comment 3•15 days ago
•
|
||
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.
Assignee | ||
Comment 4•7 days ago
•
|
||
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.
Assignee | ||
Comment 5•7 days ago
|
||
Assignee | ||
Comment 6•7 days ago
|
||
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.
Assignee | ||
Comment 7•3 days ago
|
||
Assignee | ||
Comment 8•3 days ago
|
||
Assignee | ||
Comment 9•3 days ago
|
||
Assignee | ||
Comment 10•3 days ago
|
||
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.
Updated•2 days ago
|
Description
•