Closed Bug 301104 Opened 19 years ago Closed 19 years ago

browser crashes on arabic encoding and ""[@ nsFontMetricsWin::ResolveForwards]

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 217903

People

(Reporter: hah, Unassigned)

References

()

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: 

Firefox on windows crashes with the "" characters on arabic 
encoding

Reproducible: Always

Steps to Reproduce:
1. http://members.lycos.co.uk/jann/crash.html
2.
3.

Actual Results:  
crash

Expected Results:  
not crash :)  on Internet Explorer or FF on linux,  it hides the  character
version:  1.05
Confirming that the page crashes firefox on Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b4) Gecko/20050716 Firefox/1.0+ ID:2005071610
worksforme linux 1.0.4 and trunk 20050715; crashes dpa2 win98. not getting talkback
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050716 Firefox/1.0+
ID:2005071622

Doesn't crash for me and the font shows up fine.
no like i said,  its in windows but not linux.
but for some reason  the �� is still hided, and not visable in IE or FF on 
linux,  maybe this is also a bug?  characters which dont show up at all is not 
normal i think
Attached file testcase
This testcase crashes (trunk Firefox build disappears immediately) for me on
load.
I don't get a crash with my debug build.
-> Layout, I guess.
Component: General → Layout
Keywords: crash, testcase
Product: Firefox → Core
Version: unspecified → Trunk
Attachment #189600 - Attachment mime type: text/html → text/html; charset=windows-1256
-> Layout, I guess.

ehm.. NOT layout, like you can read its a bug  with � and arabic encoding..  
layout has nothing to do with it,  i just found it on that page. 
>ehm.. NOT layout, like you can read its a bug  with � and arabic encoding..
He only changed the internal Component to Layout, as you can read in this bug.
And that a good guess for the component which is causing this crash.
Why Do you think that this is not caused by the Layout component inside Gecko ?
never mind i read it wrong, i thought he meant the layout of the html code..
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050715 SeaMonkey/1.0a
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB7563596G
Bug 252970 Trunk crash [@ nsFontMetricsWin::ResolveForwards] ?
Summary: browser crashes on arabic encoding and "" → browser crashes on arabic encoding and ""[@ nsFontMetricsWin::ResolveForwards]
(In reply to comment #13)
> Bug 252970 Trunk crash [@ nsFontMetricsWin::ResolveForwards] ?
Could be, although I crash with Mozilla1.7 on this bug, but I don't crash with
Mozilla1.7 on bug 252970.
Depends on: 252970
Mozilla 1.4.2 is also crashing on the testcase.

If I remove dir="rtl" from <html dir="rtl"> it is rendering, doesn't crash.
Deerpark:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=7575976

invalid, as browser was exe-installed BuildID 2005071206, but talkback was from
another folder, holding an unzipped 1.8b3: 2005071006
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=7575648
QA Contact: general → layout
the 2 links of Hermann Schwab give a Internal Server error here.

http://talkbackpublic.mozilla.org/talkback/fastfind.jspsearch=2&type=iid&id=7575
648
(In reply to comment #17)
> the 2 links of Hermann Schwab give a Internal Server error here.

Both links are working, just tested. 
http://talkback-public.mozilla.org/talkback/fastfind.jsp have me a HTTP 500
error message a hour before. Seems fastfind isn´t working 24 hours a day.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=7575976
If that link doesn´t work, try later or load the attached Talkback record:
https://bugzilla.mozilla.org/attachment.cgi?id=189616

The link in your comment is to short, seems the reply function moved the last
three digits (648) of the TalkbackId into the next line.
This bug doesn't seem to be related to bug 252970.

I have tracked the problem down this memcpy in PrepareUnicodeText():

@@ -1865,8 +1865,15 @@ nsTextFrame::PrepareUnicodeText(nsTextTr
     textLength += wordLen;
     n -= contentLen;
     if (textBuffer != nsnull) {
+//XXXrbs
+#if 1
       memcpy(textBuffer->mBuffer + dstOffset, bp,
              sizeof(PRUnichar)*wordLen);
+#else
+      for (int k = 0; k < wordLen; ++k) {
+        *(textBuffer->mBuffer + dstOffset + k) = *(bp + k);
+      }
+#endif

What is very curious is that the crash/disappearance goes away if I set
|#if 0| to use the hand-rolled copy...

smontagu might want to take a look since it is bidi specific. And it only
happens on WinXP (not Win2K). 
Flags: blocking1.9a1?
I haven't been able to reproduce on my XP. Do people who see the crash have "complex script and right to left languages" support turned on? (Control Panel | Regional and Language Options | Languages)
wfm URL + testcase Win98SE Firefox 1.0.7, 1.5RC1
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051106 SeaMonkey/1.5a

I don't see "complex script and right to left languages" support on Win98 and Win98SE, but I see arabic letters rendered in URL and testcase.
This has become WORKSFORME on current trunk and branch build. I can see the bug in a 2005-07-15 build, though.
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051108 SeaMonkey/1.5a
crash: 1.9a1: 2005082905 TB11635304W
       1.9a1: 2005083006 TB11635644Q
wfm:   1.9a1: 2005083105

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-30+00%3A00&maxdate=2005-08-31+05%3A00&cvsroot=%2Fcvsroot

Fix crash on unicode "zero width non-joiner" sequence. b=217903 r+sr=dbaron
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-30+17%3A35&maxdate=2005-08-30+17%3A35&cvsroot=%2Fcvsroot


*** This bug has been marked as a duplicate of 217903 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ nsFontMetricsWin::ResolveForwards]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: