Closed
Bug 1370112
Opened 7 years ago
Closed 5 years ago
Arrows on Tabstrip should be hidden with one only tab open
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mehmet.sahin, Unassigned)
References
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170604030205
Steps to reproduce:
Nightly 55.0a1 (2017-06-04) (64-Bit)
MacOS 10.12.5
STR:
1) Open new window
2) Open some more tabs
3) Shrink the window to very small, so that the arrows appear left/right on the Tabstrip
4) Close all tabs except one tab
Actual results:
The arrows should disappear.
Expected results:
The arrows are still there.
This is a regression since using a larger drag space on the left side of the tabs.
A screencast is attached.
Updated•7 years ago
|
Component: Untriaged → Tabbed Browser
Keywords: regression
I think the issue is here even with only one tab open.
STR:
1) open one tab
2) shrink the window to the minimum size
Result: double arrows are visible and it's impossible to close the tab (clicking on the X icon).
I tested with FF29 and the issue is already present, so I don't think it's a regression. When the width is reduced to the minimum, keeping one tab open makes visible the arrows </>. If you increase the width then reduce it again to the minimum, they disappear.
Keywords: regression
Summary: [Regression] Arrows on Tabstrip should be hidden with one only tab open → Arrows on Tabstrip should be hidden with one only tab open
Sorry, but this is definitely a regression.
Enclosed a screencast from FF53 showing, that the arrows disappear, when you close the second tab.
And enclosed a further screencast from Nightly 55 showing, that the arrows NOT disappear, when you close the second tab.
Comment 5•7 years ago
|
||
Dão, is it possible given the contrast between 53 and 55 as noted in comment #3 / comment #4 this is actually a latent regression from the perf improvements for lazier bounds/size-checking in the tabstrip that you worked on? Maybe we need to rerun something after removeTab() completes, or something?
Flags: needinfo?(dao+bmo)
Comment 6•7 years ago
|
||
(In reply to :Gijs from comment #5)
> Dão, is it possible given the contrast between 53 and 55 as noted in comment
> #3 / comment #4 this is actually a latent regression from the perf
> improvements for lazier bounds/size-checking in the tabstrip that you worked
> on? Maybe we need to rerun something after removeTab() completes, or
> something?
No, this is a consequence of bug 1355764, i.e. there's less horizontal space and thus the tab strip doesn't underflow with a single tab in a narrow window. Bug 1349555 might fix this.
Just an idea: A larger min width could may be also fix this.
Firefox has the smallest min width compared to Chrome or Safari.
Attached a screenshot.
Thanks.
(In reply to Mehmet from comment #4)
> Created attachment 8874886 [details]
> Nightly55_one_tab.mov
>
> And enclosed a further screencast from Nightly 55 showing, that the arrows
> NOT disappear, when you close the second tab.
Not on Windows. If you open a 2nd tab then close it, the arrows don't disappear for the only tab open. It's like that for many older versions.
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•