Make tab tray's scroll position remember which was the most recently active normal and private tab
Categories
(Firefox for Android :: Tabs, enhancement, P3)
Tracking
()
People
(Reporter: emanuellclaudiu, Assigned: jdelorenzo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxdroid][group4])
Attachments
(1 file)
|
3.09 MB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Android 11; Mobile; rv:131.0) Gecko/131.0 Firefox/131.0
Steps to reproduce:
After we open a private tab and want to go back to the last opened normal tab, it no longer shows in the tab tray. This affects if you have a lot of tabs open.
Actual results:
The last open normal tab can no longer be accessed, after we open a private tab and want to go back to the last open normal tab.
Expected results:
The last normal tab should always be open after we return from private tabs.
| Reporter | ||
Comment 1•1 year ago
|
||
Can this error be checked?
Comment 2•1 year ago
|
||
eclaudiu64, when you say the "last open normal tab can no longer be accessed", does that mean the last opened normal tab was closed when you switched to private browsing? Or that you expected the tab tray to still show last open normal tab without having to scroll?
| Reporter | ||
Comment 3•1 year ago
|
||
I expect the tab tray to still show the last normal open tab for easier access when switching from a private tab.
Comment 4•1 year ago
|
||
The Tabs Tray will always open to the initial tab page based on whether the user is in normal or private browsing, so I don't think we want to change that behavior because the last-active/accessed tab was a normal tab when there are no open private tabs. Put another way, as long as the user is in private browsing mode (PBM), the Tabs Tray should always first open to the Private tabs page.
That being said, we might still have an opportunity to remedy the following experience bug/paper-cut:
We currently don't track the last active normal tab and the last active private tab. Fenix instead only tracks the last active tab regardless of the browsing mode. So, in this situation, when the last active private tab is closed, we open the Tabs Tray to see the Private tabs page (which is correct) but the normal page is scrolled to the top, since the active/selected tab is now null. We could look into changing this behavior so the app maintains two last active/accessed tabs (one for normal and one for private).
Comment 5•1 year ago
|
||
Sounds like a good enhancement.
Comment 6•1 year ago
|
||
As someone who switches between normal tabs and private tabs a lot, it has been a real frustration to have to hunt for the normal tab again. I'm grateful that this bug will remedy that.
Updated•3 months ago
|
Updated•3 months ago
|
| Assignee | ||
Comment 8•17 days ago
|
||
Notes from Product:
"I think this change makes sense 100%, but I want to make sure that this is also happening on the new tab tray that is being worked on. I would do the change directly there if that is easier (maybe this logic was not refactored at all)."
From Noah:
"This capability is not present in the updated UI either. This could require some breaking changes to the underlying business logic, but we can aim to keep the existing Tabs Tray working as it does today."
Comment 9•14 days ago
|
||
This is one of those QOL improvements that will need to happen eventually anyway. Regarding breaking changes, that will also need to happen eventually given that each tab is currently a new window. So it probably makes sense to address all the breaking changes together, so things like remembering tabs, grouping tabs and searching tabs, sharing multiple tabs, can all happen seamlessly and efficiently.
| Assignee | ||
Updated•3 days ago
|
Description
•