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)

35 Branch
defect
Not set
normal

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)
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.
Adding Kairo since this is on Gum.
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?
Blocks: 1053434
Component: Tabbed Browser → Theme
Flags: needinfo?(MattN+bmo)
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
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)
Whiteboard: [mozmill]
Cosmin, can you please confirm if this is fixed on the latest Gum builds?
Flags: needinfo?(cosmin.malutan)
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
Flags: needinfo?(MattN+bmo)
Which patch / bug fixed that? As long as we do not know that it's WFM.
Resolution: FIXED → WORKSFORME
@Whimboo, comment 4, it's bug 1093820, it's secure.
Resolution: WORKSFORME → FIXED
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.
Depends on: 1093820
Resolution: FIXED → WORKSFORME
Whiteboard: [mozmill] → [gum][mozmill]
No longer depends on: 1093820
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?"
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.