107669 - tab buttons do not resize themselves correctly [with large screen size]

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Phillip Rhodes]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; COM+ 1.0.2204)
BuildID:    2001102903

when there are 5 or fewer active tabs, the size of the tab buttons appears to 
be wrong.  As long as there are 6 or more tabs open, the tab buttons are sized 
so that the total area they take up is about 90% of the tab bar, leaving some 
room to the right.  This appears to be the correct behavior.

However, as long as the number of tabs is less than 5, the total area consumed 
by the tab buttons is about 1/8'th of the total area of the tab bar, with the 
very narrow tab buttons bunched a tthe extreme left of the bar.

Reproducible: Always
Steps to Reproduce:
1.Launch mozilla.
2.Observe that the initial tab button is very small ( only about 3 
characters of the site title are displayed )
3. hit CTRL+T to open tabs 2, 3, 4 and 5. 
4. Observe that the subsequent tab buttons are also very small, and all the 
tabs are bunched at the left edge of the screen
5. hit CRTL+T again to open tab #6.
6. note that the tab buttons now resize themselves correctly.

Actual Results:  Tab buttons were displayed incorrectly as long as the number 
of active tabs was 5 or less.

Expected Results:  Initial tab(s) should size themselves proportionally, to 
consume a constant part of the tab bar, up to some maximum size per tab button.

Windows NT server 4.0, x86.  Using 1600x1024 screen resolution.

Comment 1

[Phillip Rhodes]

ignore the user-agent listed in the description above. I had to submit this bug 
using IE, due to a different problem.  I then forgot to take the IE user-agent 
string out of the description.

Comment 2

[John Morrison]

works correctly for me, win2k current trunk.

Comment 3

[Phillip Rhodes]

Attachment: Screen shot, with 1 active tab

Comment 4

[Phillip Rhodes]

Attachment: Screen shot with 2 active tabs

Comment 5

[Phillip Rhodes]

Attachment: Screen shot with 3 active tabs

Comment 6

[Phillip Rhodes]

Attachment: screen shot, with 6 active tabs

Comment 7

[David Hyatt]

I suspect this is just fastload file badness.  Delete your XUL.mfl file from
your profile dir.

Comment 8

[Phillip Rhodes]

Deleted XUL.mfl from the profile directory, still seeing same behavior.

Additionally, I have noticed that this behavior is affected by the size of the
mozilla window.   When I resize mozilla to about 1/2 of my total screen width, I
get proper tab sizing, even with only one or two tabs open.

Comment 9

[Phillip Rhodes]

Attachment: screen shot, 1 tab, displaying correctly

Comment 10

[Phillip Rhodes]

Have also found that the tabs behave correctly, in this regard, when I lower my
screen resolution to 1024 x 768.

Comment 11

[John Morrison]

Very odd. I boosted my display up to 1600x1200 (from 1280x1024), and I can 
reproduce this in win2k. Most likely some window and/or box bug in calculating 
available space.

Comment 12

[John Morrison]

Um, so I was showing this to hyatt, except, well, I can't make this happen 
anymore. Phillip, is this still happening in a build from today? [Very weird].

Comment 13

[Phillip Rhodes]

John, I'm still getting the exact same behavior, using build 2001103103. 

Comment 14

[Phillip Rhodes]

Attachment: screen shot, with 4 active tabs, from build 2001103103

Comment 15

[John Morrison]

*** Bug 108301 has been marked as a duplicate of this bug. ***

Comment 16

[Tuukka Tolvanen (sp3000)]

*** Bug 109248 has been marked as a duplicate of this bug. ***

Comment 17

[David Härdeman]

I'm seeing this on both Linux and Windows, build 2001110121

Comment 18

[John Morrison]

*** Bug 111275 has been marked as a duplicate of this bug. ***

Comment 19

[John Morrison]

*** Bug 111433 has been marked as a duplicate of this bug. ***

Comment 20

[Gilles Durys]

*** Bug 111592 has been marked as a duplicate of this bug. ***

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 111618 has been marked as a duplicate of this bug. ***

Comment 22

[David Härdeman]

I tested this on Linux build 2001111909 to get some numbers on what is "large
screen size". Results:

1195 pixels width - Tabs appear normally
1196 pixels width - Tabs become really tiny

This works in both ways (i.e. it switches "mode" regardless if I'm going from
larger to smaller size or the other way around)

Comment 23

[Tet]

Attachment: Screenshot showing narrow sidebar problem

While the presence of a sidebar definitely affects whether the tab
labels are displayed correctly, it has to be sufficiently wide. I
suspect this is actually a by product of just ensuring that the
visible display area is sufficiently narrow to not trigger the bug.
See the attached screenshot.

FWIW, without a sidebar, a 1213 pixel wide window works fine for me,
while a 1214 pixel wide window doesn't. This is on both 1600x1200
and 1920x1440 displays under Linux.

Comment 24

[Tet]

Having just checked, it seems my 1213/1214 pixel wide display corresponds
to an 1199/1200 pixel wide main HTML pane in Mozilla.

Comment 25

[Tsutomu Yamada]

Attachment: adhoc flex size patch (test with mozilla-0.9.6)

A tab size is calculated by layouter
(layout/xul/base/src/nsSprocketLayout.cpp?)
But I think tabbox flex was too big for it. (Why they use 100000?)

Comment 26

[Niklas Mehner]

*** Bug 112219 has been marked as a duplicate of this bug. ***

Comment 27

[R.K.Aa.]

*** Bug 112256 has been marked as a duplicate of this bug. ***

Comment 28

[John Morrison]

*** Bug 113113 has been marked as a duplicate of this bug. ***

Comment 29

[Steve Wills]

I can confirm that the proposed patch works.

Steve

Comment 30

[R.K.Aa.]

*** Bug 113619 has been marked as a duplicate of this bug. ***

Comment 31

[David Härdeman]

10 dups menas this should be marked mostfreq, right?

Comment 32

[Niklas Mehner]

*** Bug 113786 has been marked as a duplicate of this bug. ***

Comment 33

[R.K.Aa.]

*** Bug 114335 has been marked as a duplicate of this bug. ***

Comment 34

[Killian Breslin]

*** Bug 114610 has been marked as a duplicate of this bug. ***

Comment 35

[Niklas Mehner]

*** Bug 114884 has been marked as a duplicate of this bug. ***

Comment 36

[Niklas Mehner]

-> Added keywords

15 dups, and the patch is only a 2 line change ... perhaps somebody can review
this, and check it in !?!

Comment 37

[Håkan Waara]

Comment on attachment 59299 [details] [diff] [review]
adhoc flex size patch (test with mozilla-0.9.6)

It looks safe to me. 
I bet it was a hack/workaround for something else though (why would anyone
otherwise set flex to such a big value?)

Have you tested this thorougly too?

r=hwaara... hyatt: sr=?

Comment 38

[Niklas Mehner]

I cannot find any problems with a flex value of 1.

The change from flex 1 to 10000 has been made between revisions 1.8 and 1.9 (Oct
25):
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=tabbrowser.xml&root=/cvsroot&subdir=mozilla/xpfe/global/resources/content/bindings&command=DIFF_FRAMESET&rev1=1.8&rev2=1.9

Comment for the checkin is:
Fix for bug 105587, tabs should support autohide, also other tabbrowser fixes. 

Not very helpful, since this is probably one of the "other fixes" ... Perhaps
hyatt still knows what this was for.

Comment 39

[John Morrison]

*** Bug 116517 has been marked as a duplicate of this bug. ***

Comment 40

[Boris Zbarsky [:bzbarsky]]

*** Bug 116812 has been marked as a duplicate of this bug. ***

Comment 41

[Niklas Mehner]

*** Bug 116893 has been marked as a duplicate of this bug. ***

Comment 42

[John Morrison]

*** Bug 118693 has been marked as a duplicate of this bug. ***

Comment 43

[David Hyatt]

Reassigning to new component owner.

Comment 44

[John Morrison]

This worksforme on win2k with a 1600x1280 screen (current trunk build).

Can anyone esle still reproduce this?

Comment 45

[HoYin Au]

It still does it, on W2K 1600x1200, maximized, build ID: 2002012103

Comment 46

[Julien Cegarra]

Could someone go to comment 24 of bug 113798 to check if the patch fix this bug ?

Comment 47

[R.K.Aa.]

*** Bug 122155 has been marked as a duplicate of this bug. ***

Comment 48

[jag (Peter Annema)]

*** Bug 122020 has been marked as a duplicate of this bug. ***

Comment 49

[Matthias Versen [:Matti]]

*** Bug 122220 has been marked as a duplicate of this bug. ***

Comment 50

[R.K.Aa.]

*** Bug 122948 has been marked as a duplicate of this bug. ***

Comment 51

[Tuukka Tolvanen (sp3000)]

*** Bug 123507 has been marked as a duplicate of this bug. ***

Comment 52

[Matthias Versen [:Matti]]

*** Bug 123657 has been marked as a duplicate of this bug. ***

Comment 53

[timeless]

*** Bug 123720 has been marked as a duplicate of this bug. ***

Comment 54

[jag (Peter Annema)]

The reason 100000 was chosen is because the flex needs to be so much greater 
than the flex on the spacer that the spacer won't compress the tabs 
unnecessarily. See the next two attachments to see what I mean.

Comment 55

[jag (Peter Annema)]

Attachment: flex="1"

Comment 56

[jag (Peter Annema)]

Attachment: flex="100"

Comment 57

[jag (Peter Annema)]

Attachment: Use flex="100"

A flex of 100 keeps the spacer from compressing unnecessarily, and from what I
understand it avoids the bug some people are seeing with the tabs being too
small when there are only a small number of them.

Comment 58

[jag (Peter Annema)]

*** Bug 122791 has been marked as a duplicate of this bug. ***

Comment 59

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 68101 [details] [diff] [review]
Use flex="100"

sr=[e-mail]

Comment 60

[Brian Ryner (not reading)]

Comment on attachment 68101 [details] [diff] [review]
Use flex="100"

r=bryner

Comment 61

[jag (Peter Annema)]

-> 0.9.9

Comment 62

[Matthias Versen [:Matti]]

*** Bug 124876 has been marked as a duplicate of this bug. ***

Comment 63

[jag (Peter Annema)]

Smaug: I checked in your 100000 -> 100 fix. Thanks for the idea.

Comment 64

[Boris Zbarsky [:bzbarsky]]

*** Bug 126132 has been marked as a duplicate of this bug. ***

Comment 65

[R.K.Aa.]

*** Bug 126680 has been marked as a duplicate of this bug. ***

Comment 66

[Alfonso Martinez]

*** Bug 127328 has been marked as a duplicate of this bug. ***

Comment 67

[Boris Zbarsky [:bzbarsky]]

*** Bug 130029 has been marked as a duplicate of this bug. ***

Comment 68

[Boris Zbarsky [:bzbarsky]]

*** Bug 130032 has been marked as a duplicate of this bug. ***

Comment 69

[sairuh (rarely reading bugmail)]

appears to be working fine, using 2002.03.13.09 comm bits on win2k, with
resolution set to 1600x1200.