As a user I want to be able to quickly switch back and forth between tabs by swiping right and left on the address bar.
For left-to-right languages the oldest tab is on the left and a left swiping brings you to your most recent tabs.
For right-to-left languages the oldest tab is on the right and right swiping brings you to your most recent tabs.
Gives us this feature pls pls pls
I'd like to work on it
This should be tested with Android Q to see how it interacts with the new navigation gestures.
Dupe of #1283 / #176
@kbrosnan
It may be a dupe, but please compare the upvotes of this issue to the issues this is a dupe of. The discoverability of this issue is way higher, so please don't ignore this issue when assessing the importance of this feature.
@mozilla-mobile/ux please consider this for the tab management re-design
removing the ux label - this is on our radar already as it's part of Q3 plans.
Just had an idea that I would like to mention - I would also like this feature implemented but quite a few people I assume also like being able to use this gesture to see the full URL as is currently the case in Fennec. Could there be an option to switch between the two if they are ever both added?
@kbrosnan
It may be a dupe, but please compare the upvotes of this issue to the issues this is a dupe of. The discoverability of this issue is way higher, so please don't ignore this issue when assessing the importance of this feature.
Pretty sure it is a dupe of https://github.com/mozilla-mobile/fenix/issues/396
Following #10548 , the gesture to swipe down (or up) the address bars to trigger the tabs overview could be useful as well.
Starting to look into this now. One question for UX: do we want this gesture to work on the home page and if so, how would it work (what tabs would swiping go to, should we be able to swipe from a tab to the home page)? Its a bit weird since the home page isn't a "real" tab but we do show a toolbar there.
@person808 Not UX, but my feedback is that we should treat the home page as a real page and that the place in the tab stack should be where a new tab would appear if someone tapped on a top site or opened a url or search.
It would be far simpler if it were simply a tab, of course.
@yoasif Interesting idea! New tabs appear at the top of the tab tray but I'm not sure if thats treated as the first or last tab internally. So effectively the home page would be treated as the first or last page (depending on the internal tab order). The home page is a special case so if we end up supporting the gesture there it will probably be the last bit I'll work on.
Did some investigation into how similar gestures function.
Android 10 overview: In LTR layouts, the most recent app is the rightmost card in the overview. In RTL layout, the most recent app is the leftmost card in the overview.
Chrome: Regardless of layout direction, the newest tab is the rightmost tab. You always swipe left-to-right to go to an older tab. Eyeball test says that Chrome will consider the gesture complete (ie completes the tab switch animation) if you swipe about 20% of the toolbar width.
@brampitoyo @apbitner Could one of you take a look at the wip gesture and see if theres anything that needs tweaking? Ignore minor animation weirdness like the home page "save to collection" appearing for a split second
Here are some concrete values I'm using right now:
Do we want to allow swiping to the home page in the way @yoasif suggested? I have that partially implemented (swiping from a tab to home page, but not swiping from home to a tab), but its definitely one of the trickier things to get right so I won't complain if you don't want it 😄. Swiping from home to a tab is likely easier to implement than the reverse gesture since we already have thumbnails of each webpage so implementing only half of @yoasif's suggestion could be a possibility as well.
I personally would like to be able to swipe home->tab and tab->home
@person808 For now, I would recommend not including the home screen. Swiping is another way to navigate the tabs in the tab tray and since it's not included there let's leave it out for now, knowing that we could always add it later after further investigation. Let me know if you feel strongly otherwise @brampitoyo.
Layman's perspective incoming: being able to swipe to a new tab page like that with a single gesture is a massive usability plus IMO. Would be awesome to keep that if possible.
Edit to note: the tab tray does have a way of opening a new tab by pressing the new tab button visible there, but there is no way currently of opening a new tab directly from an open normal tab without going through the tab tray. Usually when I'm opening a new tab I'm doing so from the very last tab, which this would handle perfectly as a use case.
Layman's perspective incoming: being able to swipe to a new tab page like that with a single gesture is a massive usability plus IMO. Would be awesome to keep that if possible.
it would be awesome. Maybe it could be sort like, home page/tab/tab/.../tab/New tab page
If we return to the original intent of this design, we’ll find that it’s centred around quickly switching back and forth between tabs.
I’m not disagreeing with the notions put forth by @szbergeron @Neikon @person808 and others, that there could be some value in swiping to open a new tab, but it causes an additional problems that we must first solve.
This gesture was meant to go exclusively in two directions – however way you think of it: up and down the tab list, left and right, previous and next, back and forth, etc.
It’s also meant to go only one way. Meaning: if you’re on the first tab, swiping right does nothing. If you’re on the last tab, swiping left does nothing.
Being able to create a new tab breaks the simplicity of the concept, if you will. It means that this gesture is no longer exclusively navigational, but also used for something else. Now it’s got the power to invoke a new object of the same type.
Further, we now need think about other issues:
From these observations, it seems as if swipe-to-switch and swipe-to-open are two separate concepts, which should be differentiated in the app somehow. How exactly? This takes some more thinking with our limited time and resource, and please feel free to continue contributing ideas.
For this reason, I recommend separating swipe-to-open new tab into a new issue, so we can fully flesh it out while shipping swipe-to-switch in the meantime.
@brampitoyo totally agree and thanks for unpacking it.
Let's keep this issue focused on "Swipe to Switch" and move forward with the ENG work - with the goal of shipping this in nightly and testing it.
@brampitoyo @vesta0 To clarify, my comment about the tab switcher working to navigate to new tabs was only in the case where a user either opens a new tab via the tab switcher context menu or the tab tray FAB.
So it would look like:
In this scenario, because Fenix doesn't actually open a new tab in step 2, the user finds that the tab that they opened can't be navigated to.
I agree on the overall point that swipe to create may not be a great idea - but that isn't the issue I would like to prevent.
The solution to the issue above (imo) is to just have the new tab be a new tab, instead of an intermediary access point on the road to creating a new tab - that would solve the issue above.
Works fine for me. However, it is unintuitive because the tabs tray shows the tabs in the reverse order. I think there was an issue open for that so that the tabs tray displays the tabs in the correct order, however I cannot find that issue right now. I just hope, it gets implemented soon.
Edit: found https://github.com/mozilla-mobile/fenix/issues/10365 and https://github.com/mozilla-mobile/fenix/issues/11376 , but they don't seem to be prioritized at the moment :(
@sheepycoder where did you get the build from?
@andreicristianpetcu This feature is available on latest nightly.
Hi @andreicristianpetcu you can get the nightly directly from taskcluster they are here https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.nightly.latest . So you can grab them before they hit play store.
Thank you! I was getting it from here https://firefox-ci-tc.services.mozilla.com/tasks/index/project.mobile.fenix.v2.fennec-nightly/latest
@sheepycoder If I'm understanding you correctly, you're saying the way we order tabs is unintuitive? But its not a bug in the gesture itself where the tab order in the gesture isn't matching the order in the tab tray (topmost tab in tab tray = right most tab in the gesture, swiping left-to-right navigates "downward" in the tab tray). Just want to make sure there's not a bug where the tab order in the tab tray and in the gesture get out of sync.
@person808 Yeah, there is no bug in the gesture.
Gesture works fine for me, although I sometimes trigger the system gesture for quickly switching apps. I probably just need to get used to it, i.e. to swipe a bit higher on the address bar. Regarding the tab order, I like the suggestions in #11376.
it works well for me. I was hoping it was the most left tab = top tab, too. I think it's more intuitive (most left tab= top tab) and Chrome does it like this. Maybe, it would be easier for new users if we order it the same way
@Neikon yeah, that is a bug with how the tabs are displayed in the tabs tray. That will be fixed some day, though AFAIK they are low priority as of now.
@person808 there is a bug when you open a website(tab A) and scroll down the page and then swipe to another tab(tab B) and swipe again to the previous tab(tab A) you will see older tab preview/thumbnail when it was opened.
@Neikon @Scripterr Could you open new issues for your comments? I don't want feedback to get lost in here. Feel free to tag me in the new issue :)
Edit: this applies to any bugs/feedback anyone has
Verified as fixed on Nightly, 7/27.
Devices:
Pixel 3, Android 11 emulator.
Pixel 4, Android 10
Htc Desire 820, Android 6.0.1
Nexus 9, Android 7.1.1
Known issue left: https://github.com/mozilla-mobile/fenix/issues/12865
Found another bug on this https://github.com/mozilla-mobile/fenix/issues/13127
This issue is listed in the beta 80.0.0 release notes but the gesture is disabled in the release.
Most helpful comment
https://streamable.com/69gd69
@brampitoyo @apbitner Could one of you take a look at the wip gesture and see if theres anything that needs tweaking? Ignore minor animation weirdness like the home page "save to collection" appearing for a split second
Here are some concrete values I'm using right now:
Do we want to allow swiping to the home page in the way @yoasif suggested? I have that partially implemented (swiping from a tab to home page, but not swiping from home to a tab), but its definitely one of the trickier things to get right so I won't complain if you don't want it 😄. Swiping from home to a tab is likely easier to implement than the reverse gesture since we already have thumbnails of each webpage so implementing only half of @yoasif's suggestion could be a possibility as well.