86532 - outliner doesn't display large fonts properly

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[klui]

I use 100dpi fonts by default on my X environment under FreeBSD and the URL and
email LDAP autocomplete drop down menus don't display the font's characters'
full height.

Font display size is kept at the default of 96dpi.

Comment 1

[Alec Flett]

reassign to hewitt - this is skin stuff I believe

Comment 2

[Joe Hewitt (gone)]

I've seen this when increasing my system font size on windows as well.  It
happens with all outliners.  I bet this is a dup.

Comment 3

[Joe Hewitt (gone)]

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

Comment 4

[David Hyatt]

Outliner does not intrinsically size rows.  The row size is fixed.  

Comment 5

[basic]

Is there a workaround for this?

Comment 6

[Jan Varga [:janv]]

What about increasing global row height if font height is greater than row
height.
Taking for now.

Comment 7

[Jan Varga [:janv]]

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

Comment 8

[Hal Black]

Attachment: Bug displayed

This is what is displayed after clicking on a few of the choices in the
expanded tree.

Comment 9

[Hal Black]

Attachment: Bug as seen in URL chooser - not enough room for fonts

This is a view of the URL chooser pulldown, which exhibits the same bug.

Comment 10

[Hal Black]

Attachment: news browser exihibiting word overlapping

This exhibits word overlapping in news without highlighting anything.

Comment 11

[Jan Varga [:janv]]

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

Comment 12

[java designer]

What on earth is going on ? Bug 87439 has been around forever (but marked
as a duplicate of this bug) while _this_ bug doesn't seem to be going anywhere.

This is a MAJOR/SEVERE bug, and occurs anywhere any text is displayed by 
the browser. Anywhere means mail, news, main browser window, url box, history,
preferences, anything.

Look at the following screenshot for example:

http://bugzilla.mozilla.org/attachment.cgi?id=53710&action=view

This should be the #1 bug to be fixed. Mozilla 0.99 is UNUSABLE because
of this 1 bug. Please change the severity of this bug to "critical".

Comment 13

[André Dahlqvist]

Adding "access" and "nsbeta1" keywords from duped bug 87439.

Comment 14

[Jan Varga [:janv]]

I believe it looks ugly, but there are other bugs too, not just this one.
We already did some progress, so be patient please ;)

Comment 15

[Jan Varga [:janv]]

Attachment: proposed fix

Comment 16

[Samir Gehani]

Nav triage team: nsbeta1+, adt3

Comment 17

[André Dahlqvist]

I applied the patch in attachment 77262 [details] [diff] [review], and I see good result with it. My
cookie manager used to display overlapping text
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=72164), but now the
space between the tree elements is IMHO perfect. It remains to be seen if that
is the case for other people too.

Comment 18

[Jan Varga [:janv]]

Yeah, I tested on Linux and Windows
It seems that |height: 1.3em| whoud be a bit better, especially for Windows

seeking r/sr
bryner, hyatt:
I added |min-height: 18px| and changed height to |height: 1.3em|
The final height is aligned to even number.
I also moved GetRowHeight() to Init() like GetIndentation()
Do you see any need to keep calling GetRowHeight() elsewhere as Init() ?

Thanks

Comment 19

[Brian Ryner (not reading)]

Comment on attachment 77262 [details] [diff] [review]
proposed fix

r=bryner

Comment 20

[David Hyatt]

Comment on attachment 77262 [details] [diff] [review]
proposed fix

sr=hyatt

Comment 21

[[e-mail]]

IMHO it would be nice if the outliner could automatically calculate the row
height from the font plus any border/margin/padding that the skin may have set
on the row/cell/text subject to any (minimum) height set on the
row/cell/image/twisty.

Comment 22

[Jan Varga [:janv]]

it would be easy for row, but for cell and text it would be much harder

Comment 23

[Asa Dotzler [:asa]]

Comment on attachment 77262 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 24

[Jan Varga [:janv]]

fixed

Comment 25

[Hal Black]

This bug is still present in the URL autocomplete chooser.  Note, it looks fine
when you push the arrow in the URL bar.  It does NOT work when you start typing
in  "www.moz"  and it fills in choices for you below the URL bar.
See attachment 74543 [details] "Bug as seen in URL chooser - not enough room for fonts":
http://bugzilla.mozilla.org/attachment.cgi?id=74543&action=view

I am using the latest nightly build where the bug is fixed in mailnews (good job
on that, BTW - looks great!)

Comment 26

[Hal Black]

Another related bug is bug 87437.  It has the same problem that mailnews had but
in the install tool.  Should that bug be marked for 1.0 also?

Comment 27

[John Morrison]

Yes, I see that, on win32, when you jack up the fonts to ~175%, the rows in the 
autocomplete dropdown begin to overlap. I'm not entirely sure, but I don't think 
that what drops down on the autocomplete is an outliner|tree; I think it's a 
menupopup with menuitems, although other menupopups size correctly. 

Hal, could you file a bug on the autocomplete dropdown ('ubhist-popup') and 
assign it to hewitt. (or, reply to this bug and tell me to file that bug :-)


(bug 87437 is not using an outliner, so this bug does not apply to that 
situation. It's up to the installer team to decide what priority they have 
for that bug).

Comment 28

[Hal Black]

John, done.

Everyone else, if you were interested in this bug as a user, you will probably
be interested in bug 135883, which is the new identity for the url history popup
large font overlapping.

Comment 29

[J.B. Nicholson]

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

Comment 30

[java designer]

All:

This is mentioned in bug #87439 but I'll clarify this here again:

a) This bug really has *nothing* to do with the mozilla font size itself.
I am using 12 point size - within mozilla - for all my fonts and 100% font 
size (not more than that). I am running windows 2000 SP2.

b) To see what causes this bug, first don't even open Mozilla. First open
your windows display control panel, and:

b.1) under the "Appearance tab" choose a Windows extra large theme.
b.2) Under the "Settings" tab, change the font to 150%

All this does is make the display more readable when using LCD flat panels
with extra high resolution. For example, I am using a Silicon Graphics 1600SW
display with a physical resoluion of 110 dpi (and .23mm dot size). That's
an ultra fine dpi and the display would appear tiny and unreadable without 
the steps taken above. This is a common problem to many LCD panels, in fact, 
most high end new panels are very high resolution also. (see Apple 22", 
Dell xga etc).

c) *Now* launch Mozilla. You'll see that mozilla is totally messed up 
with overlapping and unviewable fonts everywhere. This is a function of the 
steps taken in (b) above, and any proposed fix *must* take into account 
the system fonts etc., as set in  (b). (the problem does not occur if step (b) 
is not carried out). Arbitrarily extending the spacing between lines is not
going to work, unless that spacing is calculated from system font dynamics.

Funny thing is *all* other applications behave perfectly on my display. Even
Netscape 4.7 renders perfectly. Netscape 4.7 is a joy to use, the rendering
everywhere is splendid and perfect, in-spite of the boosted system fonts. 

The only things keeping me from switching to Mozilla is the ugly (and in my
humble opinion, unusable) UI. I am sure many others have experienced the same
problem. I am hoping for a well thought out fix for Mozilla 1.0 ! The powers
that be may want to reopen this bug, if felt necessary.

Best regards,

[e-mail]

Comment 31

[John Morrison]

Attachment: screenshot (png) of javascript debugger, mailnews and browser menus; win2k in Extra Large Classic theme with Font Size set to 150%

What build (date) are you basing your comments upon.

Comment 32

[John Morrison]

See the screenshot attachment #79127 [details] above. 

What build (date) are you basing your comments upon. It works fine for me with 
a build from today, on win2k, in Extra Large Classic theme with fonts set to 
150%.

Comment 33

[java designer]

Your screenshot looks very good. I was basing my comments on the Mozilla 0.99
(20020311) build. My intent was to provide some background information, so that 
the final bug fix would take the interaction with system font settings into
account. 

If you also get a good result with the system's extra large font setting
boosted even *further*, then that would be great because the problem would
have been solved for the general case. 

I don't understand the internals of the rendering/spacing code, I just 
thought I'd mention my concenrns, now, while there is still some time 
before Mozilla 1.0 final. Hopefully, the barrage of email notification
each additional comment (like this) sets off won't be too annoying.

Great improvements overall and I am really looking forward to the final 
release.

Best regards,

[e-mail]

Comment 34

[John Morrison]

Okay, so Jan checked this in 10 days ago, which means it is not in the 
mozilla0.9.9 build (not surprisingly). As far as I can tell, this works
with whichever system font sizes are set (and the patch using 'em' is basing 
row height on system font sizes). 

In testing, I noticed that there may be some bugs with win2k on the first 
reboot after changing the font sizes: other applications, including Explorer, 
showed some glitches when first opened after the reboot. On one occasion, I saw 
a glitch in mozilla too, but in all cases, after restarting the app, everything 
looked fine. [And, no, I don't think I want to go hunting down the exact nature 
of this bug in win2k :-).

Comment 35

[java designer]

I can now confirm that on my winn2k box, with the Mox 1.0 RC 1 release, the
overlapping bug has been fixed. That's great ! 

*Except* there is one place the overlap still occurs: the URL autocomplete 
window. In my humble opinion, that too needs to be fixed before the final 
release. As per comments #25-28 above, I am going to file a separate bug
report for that bugid too !

Best regards,

[e-mail]