Closed
Bug 111370
Opened 23 years ago
Closed 23 years ago
Some pages are not rendered after font downloading
Categories
(Core Graveyard :: Embedding: APIs, defect, P1)
Tracking
(Not tracked)
RESOLVED
INVALID
mozilla0.9.7
People
(Reporter: hansoodev, Assigned: tetsuroy)
Details
(Keywords: topembed)
Inside of NeedFontPackage() callback, if the control returns after font installation, the page is not rendered. This is in embedding case. When Embeddor overrides fontpackagehandler with a customized handler and that handler installs font in NeedFontPackage() callback and return the control back to Gecko, sometimes the page is not rendered... However reloading it after that renderes the page with the right font which hsa been installed by the handler. NOTE : This happens only with certain pages, not every page wich needs a new font installed. Here are a couple. http://www.mainichi.co.jp/ Japanese http://www.chinacue.cn.net/ Simplified Chinese http://www.korea.com Korean. One more info I need to provide is that in this particular handler, the thread is spawned from the main thread and the child thread is responsible for installing a font. In the meantime, the main thread sits there and waits for the child thread to be done ( whether the installation was successful or not ). While the main thread is waiting, it pumps the msgs and handles them so that the waiting would not lock up the whole app. And finally when the child thread exits, if it was successful installation, the main thread broadcast WM_FONTCHANGE msg so that Gecko will be notified. For setting this particular embedding environment, please contact yokoyama@netscape.com (Roy Yokoyama) ( Roy, thank you... ) Thank.
Reporter | ||
Comment 1•23 years ago
|
||
We need this one for my company's main app and I am using 9.4 branch. Adding edt0.9.4 kw. Thanks
Keywords: edt0.9.4
Priority: -- → P1
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
CC'ing module author. Frank, do you understand what is being asked here and the best way to proceed with providing it? If I understand correctly, the Win32 font metrics code is not using the font the person has just installed, requiring the page to be reloaded manually. There is also the matter of running a message loop in the font package service while the package is downloaded. This requires pushing & popping event queues to prevent Gecko events for being processed while waiting.
Reporter | ||
Comment 3•23 years ago
|
||
Adam, "This requires pushing & popping event queues to prevent Gecko events for being processed while waiting." The code I have already do those in the font package service while the package is downloaded. Actually, it did not work at all b/f I put those codes in. Hope this info helps. Thanks.
Assignee | ||
Comment 4•23 years ago
|
||
ftang is on vacation. cc'ing nhotta
Comment 5•23 years ago
|
||
adding jst -- hoping for clues :-) last time it was the WM_FONTCHANGE notification that was causing gecko to throw out all of its frames (and crash!) could this *still* somehow be causing us problems? Is the behavior of this font package handler the same as the default one -- in particular does the default handler broadcast a WM_FONTCHANGE notification when it is done? -- rick
Assignee | ||
Comment 6•23 years ago
|
||
Rick:
>does the default handler broadcast a WM_FONTCHANGE notification when
>it is done?
No, the default handler doesn't broadcast the msg at all. We leave
the message up to the system. The font installation and the notification
msg handling is independent. (For example, when an user copies a font
to the Font folder, the system will broadcast the msg to all the applications.
We then respond to the notification.)
Assignee | ||
Comment 7•23 years ago
|
||
Adam:
>If I understand correctly, the Win32 font metrics code is not
>using the font the person has just installed, requiring the page to be
>reloaded manually.
No, we needed to re-start the browser. Font metrics code read the
available fonts at the start-up and maintained the list. But that was before we
implemented the WM_FONTCHANGE msg handler. Currently we re-construct the font
list upon receiving the notification msg and
force to refresh the page.
Hansoo: Do you receive the WM_FONTCHANGE msg for those sites?
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Assignee | ||
Comment 9•23 years ago
|
||
I tried with recent embedding client build and www.korean.com rendered fine. I can't test the japanese one; because I am using japanese OS. This may have something to do with frame. All those URLs (except one unknown due to the broken link, www.chinacue.cn.net) have frames. There is a fontdownloading related bugscape bug 11207 Parent frame charset may cause this different bahaviour: - Parent's Meta charset is "euc-kr" for www.korea.com - Parent's Meta charset is "x-sjis" for www.mainichi.co.jp - Parent's Meta charset is "iso-8859-1" for bugscape 11207 --- Changing the summary also
Summary: Inside of NeedFontPackage() callback, if the control returns after font installation, the page is not rendered. → Some pages are not rendered after font downloading
Assignee | ||
Comment 10•23 years ago
|
||
mdumm/teruko/hansoo: can you reproduce this?
Comment 11•23 years ago
|
||
minusing for now. if a reproducible test case surfaces, let's reconsider.
Reporter | ||
Comment 12•23 years ago
|
||
Roy : The broken link was given to me Teruko. http://www.chinacue.cn.net/ Simplified Chinese Strange, it worked for me at that time, but now I can not go there. Teruko : Is this static page or dynamic ? Any other way to get there ? Roy : Hansoo: Do you receive the WM_FONTCHANGE msg for those sites? I think I received wm_fontchange msg when testing a few days ago. But I will test one more time and let you know... hansoo: can you reproduce this? It was almost 1005 re-producible. Thanks.
Comment 13•23 years ago
|
||
what should we do with this bug for m0.9.7? It seem we still lack of info to reproduce this
Assignee | ||
Comment 14•23 years ago
|
||
Ok, http://www.chinacue.cn.net/ is back and it's definitely framed with charset=gb2312. I'll try to debug this with my build.
Assignee | ||
Comment 15•23 years ago
|
||
Bugscape patch fixes this bug. http://bugscape/show_bug.cgi?id=11207 It is to do with frame page.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 16•23 years ago
|
||
Teruko and Roy, For some reason, Gecko does not recognize the font installed anymore. I tested with Babel site and www.korea.com and a couple of more. After installation, the pages is freshed, but still with wrong font. They don't look right to me. It also happens with manual installation and refreshing by WM_FONTCHANGE. Any idea or same things happen to you, too ? Thanks.
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•