Closed
Bug 1094696
Opened 10 years ago
Closed 10 years ago
Tab scroll arrows are visible too early (when the tab strip shouldn't overflow yet)
Categories
(Firefox :: Theme, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1094782
People
(Reporter: cosmin-malutan, Unassigned)
References
Details
(Whiteboard: [gum][mozmill])
While opining new tabs in Australis, they will be re-sized until scrollbutton-down get's displayed, afterwards they should be hidden. With the new Gum branch they still get re-sized after scrollbutton-down get's displayed. If this is expected then we would have to update our mozmill-tests. Steps: 1 Open http://mozqa.com/data/firefox/tabbedbrowsing/openinnewtab.html 2 Mouse middle-click on one of the links until scrollbutton-down get's displayed 3 Click one more time on a different one Expected(Nightly/Aurora etc) -> The last opened is hidden and scrollbutton-down get's highlighted Actual result -> The last open tab it's visible and all tabs get's re-sized(animated)
Comment 1•10 years ago
|
||
I think the problem we are facing here is that the scroll button is shown too early. When you compare the behavior between Aurora and the developer edition you can see that the width in the latter is way larger when the button appears. Opening more tabs, the width is reduced. Then when the tabs have the same width as in current Aurora, newly opened tabs are hidden and the button flashes.
Comment 2•10 years ago
|
||
Adding Kairo since this is on Gum.
Comment 3•10 years ago
|
||
Matt, I imagine that because we're no longer doing weird overlapping things (or maybe we are?) maybe we need to adjust the min/max/ tab size and those prefs? I recall we did this for Australis, but I don't remember the details. Do you know?
Comment 4•10 years ago
|
||
Is it possible that the patch from Bug 1093820 (which includes a fix for @tabCurveHalfWidth@) would fix this? See: https://bugzilla.mozilla.org/show_bug.cgi?id=1093820#c9
Updated•10 years ago
|
Summary: New tabs re-size animations still happens after scrollbutton-down get's displayed. → Tab scroll arrows are visible too early (when the tab strip shouldn't overflow yet)
Updated•10 years ago
|
Whiteboard: [mozmill]
Comment 5•10 years ago
|
||
Cosmin, can you please confirm if this is fixed on the latest Gum builds?
Flags: needinfo?(cosmin.malutan)
Reporter | ||
Comment 6•10 years ago
|
||
It has been fixed in the last Gum tinderbox build. Thank you guys! https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/gum-linux64/1415328252/
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(cosmin.malutan)
Resolution: --- → FIXED
Updated•10 years ago
|
Flags: needinfo?(MattN+bmo)
Comment 7•10 years ago
|
||
Which patch / bug fixed that? As long as we do not know that it's WFM.
Resolution: FIXED → WORKSFORME
Reporter | ||
Comment 8•10 years ago
|
||
@Whimboo, comment 4, it's bug 1093820, it's secure.
Resolution: WORKSFORME → FIXED
Comment 9•10 years ago
|
||
Nothing on bug 1093820 indicates that anything has been landed yet. Even not on the GUM branch. So if this is fixed for you in GUM tinderbox builds, it will not be that specific bug but another one.
Reporter | ||
Comment 10•10 years ago
|
||
I didn't had access to look in to bug 1093820, but from comment 4 and comment 5 I understood that a fix has been landed: "Is it possible that the patch from Bug 1093820 (which includes a fix for @tabCurveHalfWidth@) would fix this?" "Cosmin, can you please confirm if this is fixed on the latest Gum builds?"
Comment 11•10 years ago
|
||
It was Bug 1094782, which had a reduced fix that was included in that.
Resolution: WORKSFORME → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•