Closed Bug 1813753 Opened 2 years ago Closed 2 years ago

Improve tab drawer collapse

Categories

(Fenix :: Tabs, defect, P2)

All
Android
defect

Tracking

(firefox110 wontfix, firefox111 verified, firefox112 verified)

VERIFIED FIXED
Tracking Status
firefox110 --- wontfix
firefox111 --- verified
firefox112 --- verified

People

(Reporter: aarjav, Assigned: 007)

References

Details

(Whiteboard: [fxdroid])

Attachments

(5 files)

Attached video Tab drawer closing

Steps to reproduce

  1. Open Tab drawer to view tabs
  2. 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?

(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.

Whiteboard: [fxdroid]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)
Assignee: nobody → nbond
Status: NEW → ASSIGNED

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.

Flags: needinfo?(apandya)

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.

Flags: needinfo?(apandya) → needinfo?(nbond)

Sorry, I forgot to turn on the tap reticles while recording that video. I've turned it on for future videos.

  1. 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.

  2. 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.

Flags: needinfo?(nbond)

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.

Yup! If this looks good, I'll get a review out for it, and hopefully land this on Monday.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED

This change has landed in Nightly and will be available whenever the next build is deployed.

Blocks: 1818315
Severity: -- → S3
Flags: needinfo?(cpeterson)
Priority: -- → P2

: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?

Flags: needinfo?(nbond)

: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.

Flags: needinfo?(nbond) → needinfo?(apandya)

Chris, assuming a sign off from :Aarjav, does this look like a good candidate for an uplift to Beta?

Flags: needinfo?(cpeterson)

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!

Flags: needinfo?(apandya)

(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?

Flags: needinfo?(cpeterson) → needinfo?(nbond)

It does not. It is a standalone fix, so it should be a straightforward merge process.

Flags: needinfo?(nbond)

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
Attachment #9320374 - Flags: approval-mozilla-beta?
Flags: qe-verify+
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) Approved for Fenix 111.0b7
Attachment #9320374 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Status: RESOLVED → VERIFIED
Attached video tab-tray-collapse.mp4

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.

Thanks for the detailed video, :verdi! I created a new bug for this so it doesn't get lost in closed-land: bug 1821961.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: