Some pages are not rendered after font downloading

RESOLVED INVALID

Status

()

Core
Embedding: APIs
P1
critical
RESOLVED INVALID
17 years ago
16 years ago

People

(Reporter: Hansoo Kim, Assigned: Roy Yokoyama)

Tracking

({topembed})

Trunk
mozilla0.9.7
x86
Windows 2000
topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 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
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

17 years ago
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

17 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

17 years ago
ftang is on vacation. cc'ing nhotta

Comment 5

17 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

17 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

17 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?

Updated

17 years ago
Keywords: topembed

Comment 8

16 years ago
-> roy
Assignee: adamlock → yokoyama
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
(Assignee)

Comment 9

16 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

16 years ago
mdumm/teruko/hansoo: can you reproduce this?

Comment 11

16 years ago
minusing for now. if a reproducible test case surfaces, let's reconsider.
Keywords: edt0.9.4 → edt0.9.4-
(Reporter)

Comment 12

16 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

16 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

16 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

16 years ago
Bugscape patch fixes this bug. 
http://bugscape/show_bug.cgi?id=11207
It is to do with frame page.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 16

16 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.




You need to log in before you can comment on or make changes to this bug.