Closed Bug 633500 Opened 9 years ago Closed 9 years ago

No text displayed, xul dialog, tree, etc

Categories

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

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
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
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...
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]
http://hg.mozilla.org/mozilla-central/rev/ad2df327c3c3
Status: NEW → RESOLVED
Closed: 9 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.