User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux) Build Identifier: v1.4 and 1.5 from mozilla.org 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: 1. 2. 3. 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...
When I go to Edit->Preferences->Appearance->Fonts and DISallow documents to use other fonts, this works around the problem. Btw: even mozilla.org 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 settings: 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?
The build in use is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007" - downloaded from mozilla.org (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?
about:buildconfig Build platform target i686-pc-linux-gnu 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
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 http://www.vienenbox.de/filebase/GFDWPSFO.NT/MSWBFNTS.ZIP
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.
I just untarred http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/mozilla-i686-pc-linux-gnu.tar.gz 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
No effect, problem remains. Are there any system settings that could influence this behaviour I could check?
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? mozilla.org 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 http://www.mozilla.org/quality/bug-writing-guidelines.html before filing any more bugs.
My build is as mentioned in comment #5, and it is the mozilla-i686-pc-lin~nu-1.5-sea.tar.gz downloaded from mozilla.org. 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 ;)
I think you should consider going to irc://freenode/suse and/or http://www.susehelp.org/sites/ml.php for further assistance, as this looks like a system problem rather than a mozilla.org problem. ISTR this issue on the firstname.lastname@example.org list not too long ago. You could search for it at http://lists.suse.com. If this was a generally reproducible mozilla.org 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
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: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.