Closed Bug 633500 Opened 14 years ago Closed 14 years ago

No text displayed, xul dialog, tree, etc

Categories

(Core :: Layout: Text and Fonts, defect)

x86
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: alice0775, Assigned: jfkthame)

References

Details

(Keywords: regression, Whiteboard: [hardblocker])

Attachments

(5 files)

Attached image screenshot (deleted) —
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110211 Firefox/4.0b12pre ID:20110211030400 No text displayed, xul dialog, tree, etc Reproducible: Always Steps to Reproduce: 1. Start Minefield with new profile 2. Help > About Minefiled 3. Actual Results: No text Expected Results: Should draw text Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/98cf4955a4b5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110210 Firefox/4.0b12pre ID:20110210052119 Fails: http://hg.mozilla.org/mozilla-central/rev/7698f12bbe7d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110210 Firefox/4.0b12pre ID:20110210052728 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98cf4955a4b5&tochange=7698f12bbe7d
blocking2.0: --- → ?
Textarea of this bugzilla page also does not show.
Sorry, str in comment #0 is wrong. Steps to Reproduce: 1. Start Minefield with new profile + userChrome.css + userContent.css 2. Help > About Minefiled 3. userChrome.css * { font-family: MeiryoKe_UIGothic; font-size:15px; } userContent.css @font-face { font-family: "MS PGothic"; src: local("IPA Pゴシック"); } @font-face { font-family: "MS Gothic"; src: local("IPA ゴシック"); }
blocking2.0: ? → ---
Aha, that's helpful - I think this must be linked to the handling of src:local(...) in @font-face. I'll try to reproduce and debug.
Attached file userChrome.css (deleted) —
reproducible userChrome.css (userContent.css is not necessary) You can download fonts formally from the following sites: License: http://ossipedia.ipa.go.jp/ipafont/index.html#LicenseEng Download page: http://ossipedia.ipa.go.jp/ipafont/download.html?ruleagreement=%E5%90%8C%E6%84%8F%E3%81%99%E3%82%8B%2FAccept Download file: IPAfont00302.zip(19.1 MB)
Umm.. I cleared fonts cache of Windows7(delete fntcache.dat and reboot). then I can not reproduce str in Comment #2. However, I can still reproduce Comment #4(the userChrome.css and the font).
So, 1.Corrupt font cache 2.@font-face in usrChrome.css Is this Invalid bug?
Note also bug 633174, which I suspect is the same underlying issue (but occurred with a specific site on OS X). I was not able to reproduce that yet, but I am still concerned there may be a real bug underlying both these reports.
I downloaded and installed the IPA fonts and userChrome.css as described in comment #4, but am not able to reproduce the problem. I see the new font being used in chrome, as expected, but no text is missing. (This is on Windows 7.)
(In reply to comment #8) > I downloaded and installed the IPA fonts and userChrome.css as described in > comment #4, but am not able to reproduce the problem. > @font-face { > font-family: "MS PGothic"; > src: local("IPA Pゴシック"); > } > > @font-face { > font-family: "MS Gothic"; > src: local("IPA ゴシック"); > } In Japanese localized version, system fonts are "MS PGothic", "MS Gothic". So, maybe "MS PGothic", "MS Gothic" should be replaced by your system font name.
OK, I have been able to reproduce something like this issue, and created a standalone testcase that shows similar behavior. (Note that the attached testcase has *two* lines of text.) It's not yet entirely clear to me how bug 633174 relates to this, but it may be affected by the specific fonts installed on the reporter's system. I'm hoping the fix (when we find it) will turn out to resolve both cases.
Assignee: nobody → jfkthame
FTR, I have verified that the testcase from comment #10 displays correctly without the patch from bug 499292, and fails (the second line is invisible) with that patch applied. Hope to have a fix later tonight...
Attached file Fail src: local(Non ASCII Font Name) (deleted) —
Fails src: local("Non ASCII Font Name")
The problem was that if the last src() fails in LoadNext(), the proxy font entry gets deleted, so it is no longer valid for us to check its mLoadingState - the actual resulting behavior may depend on what the runtime happens to do with freed memory, but it certainly isn't right!
Attachment #511820 - Flags: review?(jmuizelaar)
blocking2.0: --- → ?
Attachment #511820 - Flags: review?(jmuizelaar) → review+
Attachment #511820 - Flags: approval2.0?
blocking2.0: ? → betaN+
Whiteboard: [hardblocker]
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #511820 - Flags: approval2.0?
(In reply to comment #12) > Created attachment 511788 [details] > Fail src: local(Non ASCII Font Name) > > Fails src: local("Non ASCII Font Name") I filed a new Bug 633658 .
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: