pages using style sheets are unreadable



Core Graveyard
GFX: Gtk
14 years ago
9 years ago


(Reporter: Itzchak Rehberg, Assigned: blizzard)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



14 years ago
User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Build Identifier: v1.4 and 1.5 from

Suddenly pages using style sheets are not displayed properly (it worked last Friday, 
but now it doesn't anymore). Even a new installation (I ran 1.4 before, now updated to 
1.5) does not help. I'm pretty sure it is nothing with the preferences, since it was 
"broken" for root as well as I noticed after the update. I am not sure whether this is a 
bug or just a local problem - but I cannot remember that I changed anything on my 
machine between the last shutdown and the last boot... 
So when I load a page using CSS, images are displayed correctly. Form fields (like 
input boxes) are much smaller than usual (e.g. a field that appeared to have a width of 
at least 10 chars now looks as if it can only hold 2 chars), and from the text there's 
nothing to be seen. When I blindly mark a part of the page and paste it somewhere 
else, there is a result - so it seems as if the text is only re-set to a font size of less than 
1px. Looks very similiar to a problem I had some time ago, caused by KDE and Gnome 
font settings affecting each other. But if this would be the reason here: why does it look 
fine as soon as I disable the stylesheet in the page loaded (tried with a local page)? 

Reproducible: Always

Steps to Reproduce:
Actual Results:  
I'm pretty sure nobody can reproduce it :( Reason: if you could, you wouldn't be able to 
use Mozilla for browsing any more...

Comment 1

14 years ago
When I go to Edit->Preferences->Appearance->Fonts and DISallow documents to use 
other fonts, this works around the problem. Btw: even is affected by this, it's 
not just "special fancy" pages. But even if a font is not found on the system, shouldn't 
there always be a fallback used? One of the css I tested uses e.g. this for all font 
font-family: Verdana,Arial,Helvetica,sans-serif; 
Since on my Linux system, Mozilla doesn't find Verdana nor Arial nor Helvetica, it 
should at least use sans-serif as a general advice? The strange thing still remaining is 
the problem appearing suddenly w/o any change to the config... 
Is this an xft build you are using?  What's your DPI preference set to in the
fonts panel?

Comment 3

14 years ago
The build in use is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007" - downloaded from (the download offered for v1.5 on
Linux). I tried all available dpi (i.e. 96 - which my desktop uses, 75 and system.
What's the output if you type "about:buildconfig" in the URL bar and hit enter?

Comment 5

14 years ago

Build platform

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -g -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--disable-tests --enable-extensions=default,irc --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug --enable-optimize --disable-elf-dynstr-gc
--enable-optimize=-O2 --enable-crypto 

Comment 6

14 years ago
Which Linux? Sounds like something maybe deleting your home dir's font cache
would fix.

If you want Verdana & Arial you can get them various places, such as

Comment 7

14 years ago
It is a SuSE 8.2. The last time the file ~/.fonts-cache-1 was touched is a week
ago - so in this case the problem would have appeared earlier. But nevertheless:
the file contains only one entry (for the TTF - but none for the PS Fonts). If
that is wrong: how to rebuild (just deleting?), or if it's the wrong file: which
one to look for (the ~/.fonts/ dir is empty)?

As for the fonts, I do have them. But they are listed in Mozilla as
adobe-helvetica-* etc., so I didn't see them on my first quick look. This means:
all the fonts mentioned in my previous CSS example are available, but Mozilla
looks messed up although.

Comment 8

14 years ago
I just untarred
to /usr/local/mozilla on a SuSE 8.2 box, and it works just fine. Before I did
that, 1.5b worked fine too.  ~/.fonts.cache-1 was timestamped about an hour ago.
 On my SuSE 8.1 box, there is no such file, and neither has a font cache
directory, nor has my Fedora system..

Reporter, try these:
1-Go back to prefs and change display resolution back to "system setting".
2-Exit Mozilla completely
3-delete homedir/.mozilla/profilename*XUL.mfasl

and report back

Comment 9

14 years ago
No effect, problem remains. Are there any system settings that could influence
this behaviour I could check?

Comment 10

14 years ago
The build info in comment 5 is nothing like I get from the build in comment 8. What 
build is yours? Roll your own? From YaST Online Update? RPM?

If you create a new profile or new user, does the same thing happen?

Can you try the build in comment 8 installed as there described?

These are just things to try, as I'm just guessing what happened is maybe your
upgrade from 1.4 to 1.5 went haywire somehow. It doesn't look like a reportable
or existing Mozilla bug. Be sure to read and understand all of before filing any
more bugs.

Comment 11

14 years ago
My build is as mentioned in comment #5, and it is the
mozilla-i686-pc-lin~nu-1.5-sea.tar.gz downloaded from Creating a
new user has the same results. I don't think the build from #8 will help,
neither broke it on update (see original comment: just after a reboot it broke
with 1.4, which was the reason for me to upgrade - which didn't help). And as
mentioned before, I think there may be something with my local systems settings
that produces the problem - so in order to help you to reproduce, I need to know
what system settings / environment have influence on Mozilla in this case, so I
could check those. Although this "bug" may be a rare one, it may reappear (or
already have appeared) on other systems and just not been reported yet. Thus
knowing the source of the problem will help to prevent it in future releases
completely, and for current releases provide assistance to work around it in a
better way than just forbidding pages to use other fonts.
I meanwhile tracked it down a bit further: the problem only comes up with the
CSS setting "font-family" used. All other font settings don't cause this problem
to appear. One combination I tried was:
font-family: Verdana,Arial,Helvetica,sans-serif;
This certainly broke it - although all mentioned fonts are available. As soon as
I take verdana and arial out of the list, it looks fine again. So my next try
was to set up Verdana instead of Helvetica in the Mozilla preferences - and this
breaks the display as well! So the problem is probably caused by some font files
which got broken - or by the script that sets them up for the system. I think
the latter one is the problem: I remember that I just installed a new font to
the system before the problem came up. But that would be a problem to discuss at
another place (hints are welcome ;)

Comment 12

14 years ago
I think you should consider going to irc://freenode/suse and/or for further assistance, as this looks like
a system problem rather than a problem. ISTR this issue on the list not too long ago. You could search for it at If this was a generally reproducible Linux
build problem we would have seen a bug on 1.5, which is now 2 months old, or
1.4, which is 5 months old, long before now.
Do other programs that use X fonts (not Xft) work?  (e.g., xterm (usually))
Assignee: dbaron → blizzard
Component: Style System (CSS) → GFX: Gtk

Comment 14

14 years ago
Created attachment 161177 [details]
PDF file of web page in Firefox browser.

This seems to also be linked to the same bug. I also get the same for the Help
function with Firefox, and consistently across pages with style sheet links.
Other pages read fine.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.