Bug 240959

Created attachment 155239 [details]
the screenshot

Created attachment 155240 [details]
X server log

More combinations which I tried:

When I call "startx" instea,d I get a normal Gnome session, and the fonts in
firefox are OK.

In normal work I use framebuffer on console (fbset in /etc/rc.sysinit), and an
xorg.xonf which uses framebuffer device with a smaller resolution.  The fonts
are OK in this case.

Created attachment 155262 [details]
xorg.conf which works with framebuffer

When I start Matrox framebuffer on the console and use this xorg.conf, then the
problem disappears.

OK, I did more experiments:

I have verified that when I disable pango (export MOZ_DISABLE_PANGO=1), the
problem disappears.
It does not make any difference whether I use the "mga" driver for my matrox, or
whether I use the "fbdev" framebuffer driver.

I also discovered bug #241236, and it seems to be one of the reasons.

While Firefox defaulted to 96dpi, Pango uses the real resolution (126 dpi for
1600x1200 on my 17" monitor).
Then the fonts rendered by Pango are too big to fit into the rectangulars
computed by firefox itself.

I can reproduce the bug in two different situations:

1) When firefox is started outside the gnome environment (e.g., through twm),
then Pango uses the resolution autodetected by X server.
This is exactly the problem which made me to file this bug.

2) But the problem can happen within the Gnome environment, too:
Initially, all the fonts are tiny, because of bug #241232; to work around this,
the user goes to "System|Preferences|Fonts|buttton Details" and fills in the
real resolution.
Then firefox looks bad, as shown in the image attached to this bug, attachment
#155239 [details].

I suppose the right fix is that Firefox tells pango what resolution it uses.

Behdad, what do you think here?

Well, without pango firefox assumes a fixed 96dpi.  With pango, it takes what
your xorg reports.  Something like that.  It may be a bug in gtk's directfb bug
setting the wrong dpi.

If firefox is unable to handle anything but 96dpi that's a firefox bug.
Clamping resolution to 96dpi is increasingly broken on laptops. And Vista
systems won't care, so desktops may go the laptop high-dpi way soon

(In reply to comment #8)
> If firefox is unable to handle anything but 96dpi that's a firefox bug.
> Clamping resolution to 96dpi is increasingly broken on laptops. And Vista
> systems won't care, so desktops may go the laptop high-dpi way soon

This is totally out of context.  As I said, firefox+pango respects dpi
correctly, and ff3 even resizes images and other stuff based on dpi.

Hello Behdad,

(In reply to comment #9)
> This is totally out of context.

yes, I agree that we are losing focus, and my previous comments contributed to
it--sorry.

> As I said, firefox+pango respects dpi correctly, [...]

Unfortunately, this is not completely true.  Comment #1 shows that the list
below the location box uses the right fonts, but the size of the fields used for
those fonts does not match the actual font size.

(In reply to comment #10)
> Hello Behdad,
> 
> (In reply to comment #9)
> > This is totally out of context.
> 
> yes, I agree that we are losing focus, and my previous comments contributed to
> it--sorry.
>
> > As I said, firefox+pango respects dpi correctly, [...]
> 
> Unfortunately, this is not completely true.  Comment #1 shows that the list
> below the location box uses the right fonts, but the size of the fields used for
> those fonts does not match the actual font size.

Ok, I now see what the bug is.  Firefox itself (not the pango backend to it)
assumes a dpi-independent line height and hardcodes the combox height.

Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]

Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.