110898 - M098 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions]

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[greer]

Comment 1

[greer]

This one is showing up in the early M096 branch talkback crash reports as well
as in the Trunk. I have tried to reproduce it (with build 2001111817) but all of
the M096 crashes are on a Win95 machine.

Here is the stack with user given URLs below:

Stack Trace: 

         nsRenderingContextWin::GetTextDimensions
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsRenderingContextWin.cpp  line 2074]
         nsTextFrame::MeasureText
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 4658]
         nsTextFrame::Reflow   
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp
line 5114]
         nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp  line 1038]
         nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3675]
         nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3556]
         nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3481]
         nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3426]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2493]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2150]
         nsBlockFrame::Reflow  
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp
line 826]
         nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line
581]
         nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line
359]
         nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3169]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2372]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2150]
         nsBlockFrame::Reflow  
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp
line 826]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
         CanvasFrame::Reflow   
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp
line 570]
         nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 891]
         nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 540]
         nsBox::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
         nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 392]
         nsBox::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
         nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 653]
         nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1027]
         nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1138]
         nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1035]
         nsBox::Layout 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
         nsBoxFrame::Reflow    
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp
line 928]
         nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 753]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
         ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 576]
         nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp  line 217]
         PresShell::ProcessReflowCommand
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6017]
         PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 6072]
         ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5928]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 591]
         PL_ProcessPendingEvents       
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line
524]
         _md_EventReceiverProc 
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1072]
         KERNEL32.DLL + 0x2239f (0xbff9239f)
         0x00688c00
 
        Source File : 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/src/windows/nsRenderingContextWin.cpp
line
: 2074
     (38172423) URL: http://kbic.ardour.co.jp/~newgenji/oldbook/sgenji.html
     (38167970) URL: http://prom.alphaloop.com/i/
     (38146123) URL: http://prom.alphaloop.com/i/
     (38090557) URL:
http://www.megabbs.com/cgi-bin/readres.cgi?bo=sisou&vi=1000801879
     (38031982) URL:
http://www.megabbs.com/cgi-bin/readres.cgi?bo=lobby&vi=993360966

Comment 2

[rbs]

I suspect this may have now been fixed by my recent checkin in bug 110174.

Comment 3

[rbs]

Should that fix go in the m0.6 branch too? It is a good fix IMO.

Comment 4

[rbs]

s/m0.6/m0.9.6/

Comment 5

[rbs]

Marking FIXED per my above comment.

The stack trace here is the same as that in bug 110174 comment #2.
And looking at the crash data, http://ftp.mozilla.org/pub/data/crash-data/
the crash has stopped since the day I landed the fix for that bug.

For future reference: all the loose ends that I can think of in the font 
sub-system have now been fixed since my revamps. So if this bug re-appears, 
meaning the font sub-system is genuinely unable to find a font (e.g., in low 
memory situations), it would be alright to add a null check as indicated below 
(i.e., without the guilt of feeling that an underlying bug is being masked 
without proper investigation):

1991 NS_IMETHODIMP
1992 nsRenderingContextWin::GetTextDimensions(... with break indices ...)
[...]
2064   nsFontWin* fontWin = (nsFontWin*)fonts[0];
2065   aDimensions.ascent = fontWin->mMaxAscent;
2066   aDimensions.descent = fontWin->mMaxDescent;
2067 
2068   // fast path - normal case, quick return if there is only one font
2069   if (fonts.Count() == 1)
2070     return NS_OK;

with:
 
+       count = fonts.Count();
+       if (!count) 
+         return NS_OK;
 2064   nsFontWin* fontWin = (nsFontWin*)fonts[0];
 2065   aDimensions.ascent = fontWin->mMaxAscent;
 2066   aDimensions.descent = fontWin->mMaxDescent;
 2067 
 2068   // fast path - normal case, quick return if there is only one font
-2069   if (fonts.Count() == 1)
+2069   if (count == 1)
 2070     return NS_OK;

Comment 6

[Jay Patel [:jay]]

verified fixed.  i haven't seen this crash in recent MozillaTrunk Talkback data.

Comment 7

[greer]

Reopening. Seeing this bug on the Trunk in builds 2002-01-16 to present. 

Comment 8

[greer]

Same stack as bug 117736, with the stack ending one frame earlier in that bug. 
Probably a dupe. The latest incidents for this one began 2002-01-16.

Comment 9

[rbs]

Attachment: null check before deferencing the pointer

Comment 10

[Kevin McCluskey (gone)]

Reassigning to Don. 

Comment 11

[rbs]

Taking the bug since I have a fix.

Requesting r=shanjian, sr=waterson
http://bugzilla.mozilla.org/attachment.cgi?id=66005&action=view

The null pointer is happening because no font was found/created during glyph
resolution (not even the fallback substitute font). This usually suggests a
bigger fish, e.g., bug 117736 mentioned above (which is about the problem that
layout is kicked off when the world is being torn down), but a null font may
possibly happen when memory and other resources are low.

Comment 12

[Shanjian Li]

Comment on attachment 66005 [details] [diff] [review]
null check before deferencing the pointer

r=shanjian
I am OK with patch, but how about the big fish? Are you able to reproduce it?

Comment 13

[rbs]

Yep, see bug 117736 comment #9.

Comment 14

[Jay Patel [:jay]]

So is Bug 117736 a dup of this one?

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Any chance of getting this patch in soon?  waterson is on sabbatical, so you
might want to ask attinasi to sr.

Comment 16

[rbs]

Attachment: same safeguard -- the syntax here is based on what I said in comment #5

attinasi, sr?

Comment 17

[rbs]

Comment on attachment 70156 [details] [diff] [review]
same safeguard -- the syntax here is based on what I said in comment #5

carrying r=shanjian forward

Comment 18

[Shiva Thirumazhusai]

nominating topcrash bugs for nsbeta1. 

Comment 19

[Marc Attinasi]

Comment on attachment 70156 [details] [diff] [review]
same safeguard -- the syntax here is based on what I said in comment #5

sr=attinasi, but I would like to see an ASSERTION that fontWin is not null
before the deref, assuming that a non-zero count means that fonts[0] MUST
return a valid font.

Comment 20

[rbs]

Attachment: updated patch - includes requested assertion

Comment 21

[rbs]

Comment on attachment 71513 [details] [diff] [review]
updated patch - includes requested assertion

carrying r/sr forward

Comment 22

[Mike Shaver (:shaver emeritus)]

Comment on attachment 71513 [details] [diff] [review]
updated patch - includes requested assertion

a=shaver for 0.9.9

Comment 23

[rbs]

Checked in.

Comment 24

[Jay Patel [:jay]]

Removing [@ nsTextFrame::MeasureText] from summary, since that crash is covered
by bug 117736 (which I just verified fixed).  

However, reopening this bug for now for more investigation.  I see 3 talkback
incidents reported with 2/27 builds (after the checkin on 2/26).  Here is the
most recent incident:

 Incident ID 3447792   
Stack Signature  nsRenderingContextWin::GetTextDimensions 9192f6d0
Trigger Time 2002-02-27 15:53:55
Email Address
URL visited
Build ID 2002022709
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments
Stack Trace
nsRenderingContextWin::GetTextDimensions
[d:\builds\seamonkey\mozilla\gfx\src\windows\nsRenderingContextWin.cpp, line 1628]
nsTextFrame::MeasureText
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 4826]
nsTextFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 5292]
nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1087]
nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3737]
nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3618]
nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3543]
nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3488]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2642]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3232]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2508]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846]
nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
581]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
359]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3232]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2508]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 803]
CanvasFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 564]
nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 845]
nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 622]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052]
nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp, line 395]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052]
nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 650]
nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1062]
nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1221]
nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1070]
nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052]
nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1000]
nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 779]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 803]
ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 574]
nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line 217]
PresShell::ProcessReflowCommand
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6205]
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6260]
ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6116]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
KERNEL32.DLL + 0x2239f (0xbff9239f)
0x00648c18 

From the stack, it looks like this crash is still happening.

Comment 25

[greer]

Updating the summary with M098. Todays's data for the last ten days contains:
  M098 (nsRenderingContextWin::GetTextDimensions):       48 crashes
  Trunk (nsRenderingContextWin::GetTextDimensions):      22 crashes
 

Comment 26

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is the #3 unfixed topcrash in builds for the past few days?  Any idsea
what's going on here?

Comment 27

[rbs]

Line numbers look different. The current crashes seem to be happening in the 
ASCII path, GetTextDimensions(char *...), whereas the previous crashes where on
the Unicode path, GetTextDimensions(PRUnichar *...) and the patch only covered
there.

Comment 28

[greer]

*** Bug 128643 has been marked as a duplicate of this bug. ***

Comment 29

[greer]

Attachment: M09 and Trunk sample stacks

rbs: attached is a file with a sample of typical crashes from M099 and the
Trunk at this signature. Regarding your comment #27, if this is a different
problem requiring a different patch, can we mark this one fixed and open
another bug for the crash in the ASCII path?

There are currently 36 incidents (from 16 users) in M099 and 31 incidents (from
7 users, testing builds 3-05 to 3-13) on the Trunk.

Comment 30

[rbs]

It just needs the same kind of null checks in the other flavors of that function.
(but doing this in the dark since the crashes are no reproducable by developpers
or QAs)

Comment 31

[rbs]

I made a null-check patch and was testing for code coverage. To this end, I set 
|useAfunctions = 1| to test that all remained fine with the 'A' versions (i.e., 
this is the code that get used on Win95-Japanese -- which seems to be the 
platform where these crashes are reported).

But to my surprise, I am hitting the assertion:
  NS_ERROR("must call nsFontSubset's GetWidth");

Stack trace:
nsFontWinA::GetWidth(HDC__ * 0x330103d9, const unsigned short * 0x00126dcc, 
unsigned int 1) line 4472 + 21 bytes
do_GetTextDimensions(const nsFontSwitch * 0x001268a0, const unsigned short * 
0x00126dcc, unsigned int 1, void * 0x001268e0) line 2186 + 25 bytes
nsFontMetricsWinA::ResolveForwards(HDC__ * 0x330103d9, const unsigned short * 
0x00126dcc, unsigned int 1, int (const nsFontSwitch *, const unsigned short *, 
unsigned int, void *)* 0x012dc7f0 do_GetTextDimensions(const nsFontSwitch *, 
const unsigned short *, unsigned int, void *), void * 0x001268e0) line 4974 + 
24 bytes
nsRenderingContextWin::GetTextDimensions(nsRenderingContextWin * const 
0x03e5fe48, const unsigned short * 0x00126dcc, unsigned int 1, nsTextDimensions 
& {...}, int * 0x00000000) line 2212
nsTextFrame::MeasureText(nsIPresContext * 0x03db9b80, const nsHTMLReflowState & 
{...}, nsTextTransformer & {...}, nsILineBreaker * 0x03e21598, 
nsTextFrame::TextStyle & {...}, nsTextFrame::TextReflowData & {...}) line 4767
nsTextFrame::Reflow(nsTextFrame * const 0x03e6f930, nsIPresContext * 
0x03db9b80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 5294 + 43 bytes

==============
shanjian, care to try useAfunctions = 1 in your tree and visit: http://asahi.jp/

I would like to first confirm that nsFontMetricsWinA::ResolveForwards() that 
you added is still up-to-date and that I am not seeing things.

Comment 32

[rbs]

shanjian, did you try useAfunctions. I left it in my tree and am seeing crashes
in my browsing (MathML pages with those code points). Pretty weird.

Comment 33

[rbs]

re-assigning to shanjian.

I already have the null checks in my tree since comment #31 on 2002-03-15.

Please re-assign to me if you have a pointer as to what is happening re: my
query above. I would like to commit the null checks in m1.0.

Comment 34

[Asa Dotzler [:asa]]

Is the approved patch from 02/26/02 still valid? If not can you please obsolete
the patch? Thanks.

Comment 35

[rbs]

Comment on attachment 71513 [details] [diff] [review]
updated patch - includes requested assertion

obsoleting the patch which was already checked in.

Comment 36

[Shanjian Li]

I am working on it now. 

Comment 37

[Frank Tang]

nsbeta1+ and adt1

Comment 38

[Shanjian Li]

The direct cause of the problem is that nsFontWin is returned directly. While 
most of the A-Version is expecting the pointer of nsFontSubset. This confused the 
system in some situation, while in others it works OK. 

I traced the problem back to the changes for surrogate support. The prototype 
for nsFontMetricsWin is changed to cope with UCS4, but prototype of correspondent
nsFontMetricsWinA methods are not changed. That breaks the semantic of those virtual 
functions. In other word, methods in nsFontMetricsWin are called in place of 
nsFontMetricsWinA methods.  

Comment 39

[Shanjian Li]

Attachment: patch

Comment 40

[Shanjian Li]

rbs/attinasi, could you r/sr?

Comment 41

[rbs]

Comment on attachment 77164 [details] [diff] [review]
patch

r=rbs

Comment 42

[rbs]

Attachment: additional patch - mostly a nice-to-have now

What I had done earlier was to stick to pointers that have arealdy been null
checked to get the equivalent functionality, and add a couple of null checks.

Feel free to integrate my patch in yours. I applied your patch and I could get
MathML pages to display --albeit with lot of questions marks as usual-- when
setting the useA flag. (MathML pages exercise the font subsystem a lot because
they trigger the hunt for glyphs that are no where to be found.)

Comment 43

[Shanjian Li]

Attachment: complete patch (include rbs's nice-to-have one)

Comment 44

[Shanjian Li]

I tried the patch with top 100 websites and top 100 international sites, it 
worked fine. 

Comment 45

[Shanjian Li]

Comment on attachment 77254 [details] [diff] [review]
complete patch (include rbs's nice-to-have one)

carry over rbs review

Comment 46

[Marc Attinasi]

Comment on attachment 77254 [details] [diff] [review]
complete patch (include rbs's nice-to-have one)

sr=attinasi

Comment 47

[Asa Dotzler [:asa]]

Comment on attachment 77254 [details] [diff] [review]
complete patch (include rbs's nice-to-have one)

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 48

[Frank Tang]

adt1.0.0
1. it is one of the top crasher
2. the bug only happen on japanese win 95, won't happen on US 95 or other windows
3. the fix is local to Japanese win95 code only. the risk is very local

Comment 49

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin into 1.0. Pls verify this in Win 95 JA,
and text display on other Windows platforms.

Comment 50

[Frank Tang]

teruko can verify the patch fix J win 95 crash or not after check in. 

Comment 51

[Shanjian Li]

fix checked in. 

Comment 52

[Chris Petersen]

Since I don't have a Japanese Win 95 to verify with, could someone who has
access to this system please check it ?

Comment 53

[Teruko Kobayashi]

I have Windows 95J system.  However, when I tied to verify this on Win95 J
machine, the installer failed and displayed the error message "1114: Could not
load.  C:\Win95J\TEMP\ns_temp\xpcom.ns\bin\xpistub.dll".  I tried the different
builds, 4-15-1.00, 4-16-1.00, and 4-3-trunk. I have not succeeded installing
Netscape.  I am investigating the problem.

Comment 54

[Teruko Kobayashi]

Rui and I tried to install the Netscape on Win95 US machine.  We got the same
problem on the 4-15-1.00 and 4-04 trunk build. Any installers did not work on
Win95. I logged the Win95 installer problem in bug 137879.

Shanjian, do you have any suggestions to verify this bug?

Comment 55

[Madhur Bhatia]

have not seen any comments on this bug for almost a year now.
marking it verified based on comments