Improve tab drawer collapse
Categories
(Fenix :: Tabs, defect, P2)
Tracking
(firefox110 wontfix, firefox111 verified, firefox112 verified)
People
(Reporter: aarjav, Assigned: 007)
References
Details
(Whiteboard: [fxdroid])
Attachments
(5 files)
Steps to reproduce
- Open Tab drawer to view tabs
- Pull down the tab drawer slightly from the top, It would drag down only a bit showing a mid-point which can be considered a semi-opened tab tray. But if I pull down all the way to the bottom, it would close it correctly all the way.
Expected behaviour
No matter how much I pull down the tab tray (slightly or all the way), it should close all the way to the bottom. There should not be any midpoint where only a part of the tab tray is visible.
Actual behavior
Device information
- Firefox version: 109
- Android device model: pixel 6
- Android OS version: 13
Any additional information?
Comment 1•2 years ago
|
||
(Per conversation with Aarjav)
I recognize this may be complicated by the Tabs Tray refactor. This bug is one of the UX Fundamentals we want to prioritize for Q1, but Aarjav suggested that it's not necessary to complete it right away. Ideally, if this can be fixed / improved as we migrate the Tabs Tray to compose, that might be best; but I leave that up to Noah to help determine.
If that's not appropriate - we should figure out an interim solution we can leverage before Q1 ends. Adding this to the Kanban backlog for tracking.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
The severity field is not set for this bug.
:cpeterson, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
How does this look? I've made it so the Tabs Tray will always fully collapse when swiping down to close the tray, rather than go back to the half-expanded state.
Reporter | ||
Comment 4•2 years ago
•
|
||
Thank you for the video Noah, based on the video what I can gather is
1.) You can drag and move/increase the height of the tab tray using the horizontal bar at the top of the tab tray.
2.) (As I cannot see where you are dragging/Swiping) You cannot reposition (like above) the tab tray by the tabs holding area (not sure what to call this) under the tab switcher (regular, private, synced tabs) where all the tabs are seen. Dragging up/down would scroll it, but if there is nothing to scroll, nothing would happen.
3.) A quick swipe down from the top of the tab tray using the horizontal bar would close it swiftly and not reposition it irrespective of the height of the tab tray.
I hope I am making sense.
Assignee | ||
Comment 5•2 years ago
•
|
||
Sorry, I forgot to turn on the tap reticles while recording that video. I've turned it on for future videos.
-
The tray can currently only be in two heights: half expanded (it only does this when it has <= 3 or 4 tabs) or fully expanded. If it is half-expanded, you can swipe up to fully expand it. Once it's fully expanded, the tray cannot be moved back to the half-expanded state; it can only be collapsed.
-
In the video, I was trying to convey that if you slow drag the tabs tray only halfway, it will snap back to the full expansion. Only doing a normal swipe will collapse the tray.
I hope that's a bit more clear. The behavior is essentially unchanged from what's live, other than the tray being collapsible with a single swipe, so in other words, it will no longer be possible to collapse the tray back into the half-expanded state. I'm happy to jump on a call to better explain what's going on.
Reporter | ||
Comment 6•2 years ago
|
||
Thanks for the explanation, nope that makes sense. Looks good to me.
So the next step would be to push it to nightly right? and I can test it there.
Assignee | ||
Comment 7•2 years ago
|
||
Yup! If this looks good, I'll get a review out for it, and hopefully land this on Monday.
Reporter | ||
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
This change has landed in Nightly and will be available whenever the next build is deployed.
Updated•2 years ago
|
Comment 10•2 years ago
|
||
:007, can you check if there's been any fallout so far (crash increase, related regressions), and if QA has looked at it (if they haven't - make sure they have STR handy), and if yes to both, propose this an uplift?
Assignee | ||
Comment 11•2 years ago
|
||
:aarjav, whenever you have a chance, can you please verify on a Nightly build that the new behavior is what we were shooting for here? If this looks good to you, we can uplift this to Beta to get it to users sooner.
Assignee | ||
Comment 12•2 years ago
|
||
Chris, assuming a sign off from :Aarjav, does this look like a good candidate for an uplift to Beta?
Reporter | ||
Comment 13•2 years ago
|
||
Hey Noah,
So I tested it, seems to be working fine. No known issues were noticed, the original bug in my opinion has been fixed.
Thanks for the quick fix!
Comment 14•2 years ago
|
||
(In reply to Noah Bond [:007] from comment #12)
Chris, assuming a sign off from :Aarjav, does this look like a good candidate for an uplift to Beta?
Sure! Since your fix is small and Aarjav thinks it looks good, this sounds like a good candidate for uplift. Does this fix depend on any other code changes in Nightly 112 that aren't in Beta 111?
Assignee | ||
Comment 15•2 years ago
|
||
It does not. It is a standalone fix, so it should be a straightforward merge process.
Comment 16•2 years ago
|
||
Assignee | ||
Comment 17•2 years ago
|
||
Comment on attachment 9320374 [details] [review]
[mozilla-mobile/firefox-android] Bug 1813753 - Skip the half-expanded state when collapsing the Tabs Tray (backport #874) (#1042)
Beta/Release Uplift Approval Request
- User impact if declined: Users will just get this UX improvement on the regular release trains.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Steps are in the ticket, but the Tabs Tray should now collapse in one swipe instead of being first collapsed to its half expanded state.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a one-line change to the collapse behavior of the Tabs Tray.
- String changes made/needed:
- Is Android affected?: Yes
Assignee | ||
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Managed to reproduce the issue on the build on which this was discovered on.
Verified as fixed on the latest Nightly 112.0a1 (2023-03-01) and on the latest Beta 111.0b7 builds.
Device used: Google Pixel 7 (Android 13).
Marking the issue as Verified fixed for both 111 and 112.
Updated•2 years ago
|
Comment 20•2 years ago
|
||
The collapse of the tab tray is nice a smooth now. But after seeing it in action, it seems to accentuate the delay of the removal of the scrim and FAB. We'd like to have the FAB animate out with the tray and the scrim to dissolve at the same time. I mocked it up in a video to help explain.
Comment 21•2 years ago
|
||
Thanks for the detailed video, :verdi! I created a new bug for this so it doesn't get lost in closed-land: bug 1821961.
Description
•