Fenix: Reverse the direction that Fenix adds new tabs from

[ghost]

• A user on Reddit is asking this feature;

Currently Fenix adds new tabs to the top but chance it so that it adds the new tabs one after the other in a downwards direction like how Chrome does it.

Now if you ask me which one I prefer I don't know. I have been using Fenix since it launched from early last year and I haven't had any problems navigating through tabs. Perhaps a switch to change the direction could be added to satisfy the both types of users and since tab navigation is one of the central features of a browser this should be a customisable behaviour.

[tukusejssirs]

I wish the new tabs would be added the same way as on the desktop FF:

1. when opening a new tab (empty one, about:blank), it would append it to the bottom of the list;
2. when opening a tab with _Open link in new tab_, it should be open right after (below) the tab I am currently on; if multiple links are open this way (without changing the currently open tab), they should be appended to each other (i.e. current_tab, first_new_tab, second_new_tab, third_new_tab, …, nth_new_tab, following by the other, already open tabs).

The current behaviours drives me nuts as it changes the order I am used to and that makes sense (to me).

[liuche]

Copying over a comment from another user issue. This is maybe something we can consider -- but I can't remember, did we already decide to do it in this direction for a reason?

What is the growth opportunity you want to see solved?
Avoid long thumb travel across the screen by reversing the tab list when using bottom navigation bar.

Why?
The new navigation bar and buttons are at the bottom of the screen. This is to easy navigation with phone getting bigger and avoid long thumb travel across the screen. But when opening the tab menu in Fenix the latest opened tabs are at the top of the screen. Those latest opened tabs have an high probability to be the destination of the user. Thus, reversing the tag lost order will easy access to more recents tabs as the user will already has touch the bottom of the screen to open the tab menu.

[Dunexus]

See https://github.com/mozilla-mobile/fenix/issues/12861 and https://github.com/mozilla-mobile/fenix/issues/12108#issuecomment-669048249

[apbitner]

@topotropic is currently looking into the way we sort various items within the app

[yoasif]

Like the rest of you, I have been using the new direction since it was changed.

Unfortunately, I have found myself accidentally closing the tab tray while trying to navigate to newer tabs. I commented about it in https://github.com/mozilla-mobile/fenix/issues/14911#issuecomment-689861357 and also filed a bug https://github.com/mozilla-mobile/fenix/issues/14476.

The biggest issue here is that even if a user has many tabs open, they are most often going to be accessing new tabs, not older ones. We implicitly recognize this from features like https://github.com/mozilla-mobile/fenix/issues/4118.

Unfortunately, even in the default bottom navigation toolbar configuration, we make it harder to access the newer tabs -- if we were optimizing for "reachability", the newest tabs would be closest to the bottom, not in the middle or top of the screen.

If we assume that most of the time people are accessing newer tabs, we also lower the chance of users accidentally closing the tab tray when accessing the tab that they were looking for, because of the infinite depth of the bottom of the screen - users will never overshoot the newest tab, closing the tab tray.

Additionally, this results in weird gestures like https://github.com/mozilla-mobile/fenix/issues/13172 because of attempts at internal consistency.

Thankfully, the good news here is that because Fennec used this order, the oldest to newest (from top of display to bottom) is already preferred by existing Firefox users, and because this order also prioritizes recency in reachability and error prevention, it should also satisfy users preferring the bottom navigation toolbar layout.

[avently]

Actually reversing the sorting will fix sooo many issues related to a bottomsheet. I vote for this too. It would prevent me from interacting with tabs top-to-bottom swipe which is counter-intuitive in the case of tabs

[LinAGKar]

For me, tabs opened with "open in new tab" being in reverse order compared to other tabs is the biggest annoyances. But it would be preferable to switch top-to-bottom order as well, and to get back the ability to manually reorder tabs. Currently, holding on tabs just highlights them for this "collections" thing I don't use, rather than letting you move them.

[andreicristianpetcu]

@LinAGKar I stopped using swipe to switch tabs since I never know if a tab is on the right or on the left.

[JohannVII]

I agree entirely the default positioning for new tabs should be a configurable option as noted, and that tabs should be reorderable.

On a related note, is there an existing issue to turn the tab manager shade into a full-screen pane like it was in Fennec, or should I start a new one? That would resolve all current accidental closure swiping issues (which I've also found to be a big problem, especially given the tab ordering logic) and prevent any introduced by misreading swipes when one is trying to reorder tabs (if we get that back), while the visual positioning of the tab list could still be set to populate from the bottom with a bottom address bar, whatever the ordering logic is, so if only one or two tabs were open, they would still be close to the address bar. I don't see the utility in leaving part of the current page visible with a shade design, because the point of going to the tab manager is to do something other than interact with the current page - save a tab, open a new tab, switch tabs, etc. - while there is utility in NOT having a shade design.

[Poopooracoocoo]

https://github.com/mozilla-mobile/fenix/issues/11376#issuecomment-642458962:

1. when opening a new tab (empty one, about:blank), it would append it to the bottom of the list;

12774

[topotropic]

Thanks for the feedback, everyone.

Makes sense to update the tab order to the following:

1. when opening a new tab (empty one, about:blank), it would append it to the bottom of the list;

2. when opening a tab with _Open link in new tab_, it should be open right after (below) the tab I am currently on; if multiple links are open this way (without changing the currently open tab), they should be appended to each other (i.e. current_tab, first_new_tab, second_new_tab, third_new_tab, …, nth_new_tab, following by the other, already open tabs).

[yoasif]

@topotropic thank you for your consideration of our feedback!

[codrut-topliceanu]

Thanks for the feedback, everyone.

Makes sense to update the tab order to the following:

1. when opening a new tab (empty one, about:blank), it would append it to the bottom of the list;
2. when opening a tab with _Open link in new tab_, it should be open right after (below) the tab I am currently on; if multiple links are open this way (without changing the currently open tab), they should be appended to each other (i.e. current_tab, first_new_tab, second_new_tab, third_new_tab, …, nth_new_tab, following by the other, already open tabs).

Point 1 will be fixed in Fenix, PR incoming shortly.
Point 2 will be fixed in AC by this issue -> and its PR.

[re-hub]

It is also reasonable to reverse the toolbar slide direction with this issue. Logically ordering in a regular ux is from top to bottom and left to right. Like you show later items on the right in a line, the newer tabs should be on the right. Top to bottom order will correspond to left to right order creating a natural ux.

[Poopooracoocoo]

I have some feedback on this change here: https://github.com/mozilla-mobile/fenix/issues/16427#issuecomment-723260055

[tukusejssirs]

I’d like to note that it might a good idea to use top-to-bottom and left-to-right direction everywhere.

For example, when I add some tabs to a collection, the text box to adc a new collection should be moved to bottom and the new collection should be appended. Currently, it is prepended.

[codrut-topliceanu]

Point 2 will be fixed in AC by this issue -> and its PR.

Correction: point 2 will no longer be fixed at the moment. See this comment

@re-hub Agreed. I think the fix for this issue has solved that problem.

[abodea]

Verified on the latest Nightly 11/17 with Google Pixel 4 XL (11).
Note that this verification is only for part 1 of this bug and we will not close it until the second part will be fixed and implemented.
Point 2 will be fixed in AC by this issue -> and its PR.
Removing the eng:qa:needed until the second part will be ready for testing and then we will add the eng:qa:verified after the bug will be verified.