Closed Bug 301104 Opened 19 years ago Closed 19 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 217903

People

(Reporter: hah, Unassigned)

References

(
URL
)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

testcase
262 bytes, text/html; charset=windows-1256
Details
Talkback Report TB7563596
34.53 KB, text/html
Details
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

Creator:
Created:
Updated:
Size: