[toolbar redesign] Navbar elements overlap in multiwindow / floating mode
Categories
(Firefox for Android :: Toolbar, defect, P2)
Tracking
()
People
(Reporter: petru, Assigned: skhan)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxdroid][group3][toolbar-redesign-release-blocker])
Attachments
(3 files)
When in multiwindow the navbar elements overlap the url.
| Reporter | ||
Comment 1•1 year ago
|
||
When in floating mode the navbar elements overlap the url.
| Reporter | ||
Comment 2•1 year ago
|
||
Seems like this happens because the app thinks it's shown in landscape 😕 and has to use a different layout for the toolbar/navbar.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Refinement meeting note:
- this still needs some UX input to figure out how to resolve.
- Petru: application thinks it's in landscape mode because of technical considerations associated with the multi-window API
- Zac: we should consider using the viewport size to decide when to break between single bar and double bar toolbar
Updated•1 year ago
|
:aarjav Calling to have your input here. I tested with my pixel 8a and in splitscreen mode whether phone held vertically or horizontally has more widthPixels than heightPixels therefore causing splitscreen to be treated in landscape mode. This is causing the url to squeeze to a shorted or no text as seen in the videos in the description.
Suggestion: Should we always default to two toolbars when in multi mode?
Cons: It will take up a lot of space compared to what little screen space we have in multi mode.
Comment 5•1 year ago
•
|
||
Is this dependent on the screen width? So if the user is on any type of screen, if the screen width is 599dp or less it should always use 2 toolbars. I tried to define that here.
Similar to Zac's suggestion from the refinement meeting.
I believe this is ready to be worked upon with Aarjav's comment. If the width is 599dp or less, we show two toolbars regardless if phone is held vertically or horizontally. That applies to multi mode and floating mode.
Updated•1 year ago
|
Comment 7•1 year ago
|
||
I believe we recently changed some of how our isTablet is determined but I'm not sure we have checks for size. We will need to investigate if we should change this toolbar setting to use a width calculation instead of the isTablet used throughout the rest of the app.
the isTablet was changed to isLargeWindow and getWindowSize as part of the AcornLayout.
After some light discussion with Aarjav, he wants to focus on Width only and not the window size, so our logic would have to be different than what Acorn Layout is providing.
As a note: Acorn Layout and the two functions mentioned above are checking width AND height.
Investigating if we could use AcornLayout sizes or not. By Tim's comment though, we might not be able to.
In any scenario, I am giving this an effort of 3, since I intend to not just do it for floating window or multi-mode but change the concept of landscape and portrait and simply utilize the concept of width less than 599dp for two toolbars.
This would require an effort to modify conditions on home screen, browser screen, swiping tab preview and custom tabs.
And would require good manual testing.
Comment 10•1 year ago
|
||
I'd argue that this could be broken into multiple tickets.
Seeing how much this impacts, might benefit from smaller tickets to make it easier to review and test.
| Assignee | ||
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
| bugherder | ||
Comment 14•1 year ago
|
||
The patch landed in nightly and beta is affected.
:skhan, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox133towontfix.
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Description
•