Open Bug 1024816 Opened 6 years ago Updated Last year

Tab overflow on horizontal tab strip

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

People

(Reporter: ywang, Unassigned, Mentored)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Tab overflow on horizontal tab strip. We can reuse some similar patterns from desktop Firefox. For example shorten the length of each tab, then dismiss the "Close" button of bg tabs. Eventually the complete overflow, which I think can be managed and understood simply by scrolling gesture with no indicators.

Next step:
* Visual refinement
* Implementation
Depends on: 1014987
Attached image prev_tabletui_overflow_mock1.png (obsolete) —
Here's a mockup of what "stage 2" overflow would look like.

The width of the entire "active" tab shrinks down to being only 125 dp while the other background tabs are 96 dp (including their own respective dividers on the right hand end of the tab.

Specs to follow
^ WIP, refining minimum size currently to keep a favicon visible.
I'm a little skeptical about overflow stage 2, specifically that the close button disappears when I get enough tabs. My desktop workflow is usually:
  1) Open a lot of tabs that I'll pretend that I will read later (e.g. using "Open Link in New Tab" on many sites from a google search result to do research)
  2) Realize some time later that I don't want/need those tabs anymore
  3) Close the ones I don't actually need

Having to select (and start loading) each tab before I can close it would likely be a slow and painful process.

Is there a fast way to close tabs in the tabs panel (the screen with tab thumbnails) or via other gestures? Maybe that would mitigate this issue.
Flags: needinfo?(ywang)
(In reply to Michael Comella (:mcomella) from comment #3)
> I'm a little skeptical about overflow stage 2, specifically that the close
> button disappears when I get enough tabs. My desktop workflow is usually:
>   1) Open a lot of tabs that I'll pretend that I will read later (e.g. using
> "Open Link in New Tab" on many sites from a google search result to do
> research)
>   2) Realize some time later that I don't want/need those tabs anymore
>   3) Close the ones I don't actually need
> 
> Having to select (and start loading) each tab before I can close it would
> likely be a slow and painful process.
> 
> Is there a fast way to close tabs in the tabs panel (the screen with tab
> thumbnails) or via other gestures? Maybe that would mitigate this issue.

Good point, Michael! 

The tab panel will have a sliding-up gesture for closing tab thumbnails, just like the current slide left/right to close tabs on Fennec but in a different direction. It's more efficient for sure than hitting the "Close" icon on tab strip.

Tab strip is great for having your tabs visible and actions accessible within a tap, but we know it's not the best place for managing and organizing your tabs. So I think in that stage 2, not having close icon is a good constraint to have. 

Once switching between tab strip and tab panel feels quick and simple, the users will see the benefit of having tab strip and panel together. They serve for separate user needs but work closely together.
Flags: needinfo?(ywang)
(In reply to Michael Comella (:mcomella) from comment #3)
> I'm a little skeptical about overflow stage 2, specifically that the close
> button disappears when I get enough tabs. My desktop workflow is usually:
>   1) Open a lot of tabs that I'll pretend that I will read later (e.g. using
> "Open Link in New Tab" on many sites from a google search result to do
> research)
>   2) Realize some time later that I don't want/need those tabs anymore
>   3) Close the ones I don't actually need
> 
> Having to select (and start loading) each tab before I can close it would
> likely be a slow and painful process.
> 
> Is there a fast way to close tabs in the tabs panel (the screen with tab
> thumbnails) or via other gestures? Maybe that would mitigate this issue.

Yeah, hopefully the new panel/tray will be the new "cmd + W" way of closing all the tabs when you have more.

Simply put, the hit areas way too small to include the 'x' even if we're being smart about the minimum size a tab and shrink to.

Speaking of! In this mock, the size is active tab is shrunk to 180 dp (down from the default 205 dp) while the background/inactive tabs are down to a 154 dp hit area (without the 'x'). 

I think this is a good balance that we should try for V1.
Attachment #8490164 - Attachment is obsolete: true
Assignee: nobody → lucasr.at.mozilla
Attached image overflow.png
Is there a plan for overflow on the right hand side near the new tab button? I can't imagine the gradient shown in these mocks will make that look less... abrupt.
Depends on: 1090364
(In reply to Wesley Johnston (:wesj) from comment #6)
> Created attachment 8502569 [details]
> overflow.png
> 
> Is there a plan for overflow on the right hand side near the new tab button?
> I can't imagine the gradient shown in these mocks will make that look
> less... abrupt.

Not on v1. We should discuss alternative approaches for v2.
Moving this to v2. We'll only be doing the fading edge for v1.
Blocks: new-tablet-v2
No longer blocks: new-tablet-v1
Assignee: lucasr.at.mozilla → nobody
Mentor: michael.l.comella, mhaigh
You need to log in before you can comment on or make changes to this bug.