Closed
Bug 263742
Opened 20 years ago
Closed 20 years ago
Linux font crash for missing/unavail/?? font
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 261543
People
(Reporter: rjhorn, Assigned: bugzilla)
References
()
Details
(Keywords: stackwanted)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041009 Firefox/0.9.1+ This site has a mouseover to trigger a font change, from verdana to tahoma, and a color change. That font change causes a crash. This crash behavior began with firefox version 0.9. If I use the option to always use my fonts, the crash does not occur. The page obviously looks different, and the mouseover only causes the color change. The bug affects many other pages, but they cause a crash during load/render. This page has the mouseover style change that helps isolate it to something specifically font related. This may be related to bug 261543. Firefox shouldn't crash for unavailable fonts. It should perhaps generate an error, and then act drop back to user default fonts. They may look wrong or different, but it's better than crashing. Reproducible: Always Steps to Reproduce: 1. load the page. (This page requires registration, so set up a dummy account if necessary. Go to www.concept2.com and select "personal logbook" to start that process.) You will need to log in to the personal logbook get to the problem page. 2. Mouseover any of the heading fields, e.g. "Challenges" 3. Actual Results: Crashes on mouseover Expected Results: Use alternative user font, perhaps with error message somewhere I'm using a SuSE 9.1 generic install and haven't done anything special for fonts. If there are specific things to check I can provide more info. There are a smattering of talkbalks for this. From time to time I try new releases to see whether this is fixed.
reporter: it'd help if you mentioned the talkbackids
Keywords: stackwanted
(In reply to comment #1) > reporter: it'd help if you mentioned the talkbackids Two from today for this new version are: TB1231810G TB1226987M
Comment 3•20 years ago
|
||
I thought I'd add my own experiences with this same bug: I receive the same
results with Firefox 0.99 and Firefox 1.0 (Ubuntu packages). It appears that, if
a font exists but is unavailable (e.g., inside a directory that is marked rw-
instead of rwx) that's when it'll fail. When rendering a page with fonts that
are simply not on my computer, Firefox will choose alternate fonts gracefully.
Unfortunately I can't find any debugging package for Ubuntu, so I can't give any
TalkBack or coredumps or anything. I do know, however, that Firefox experiences
a segmentation fault at this point (using strace):
open("/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf", O_RDONLY) = -1
EACCES (Permission denied)
open("/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf", O_RDONLY) = -1
EACCES (Permission denied)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/paul/.mozilla/firefox/default.7y4/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(6795, 6795, SIGSEGV) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
/var/lib/defoma/fontconfig.d/K/KochiMincho-Regular.ttf appears to be a symlink
that points to /usr/share/fonts/truetype/kochi/KochiMincho-Regular.ttf. I
purposefully took off the execute bit off the directory
/usr/share/fonts/truetype/kochi for the purposes of this report.
Comment 4•20 years ago
|
||
Those talkback IDs are no longer available. *** This bug has been marked as a duplicate of 261543 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•