Some title characters are missing when using non-ascii characters

VERIFIED FIXED in M14

Status

()

Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: emk, Assigned: rickg)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

18 years ago
Steps to reproduce:
1. Launch Mozilla.
2. Navigate to http://member.nifty.ne.jp/bakera/html/hatomaru.html
3. Look at the title bar.

Actual result:
See the screenshot (some characters are missing).

Expected result:
See the screenshot (using IE5).
IE5 and Nav4.7 works as expected.

I'm using [1999111808] build mozilla.exe on WinNT4 (SP5)
*Japanese* version.

This bug occurs because:
1. FindChar1() does not work correctly when fourth parameter (aChar)
   is a non-ascii character.
2. Sometimes CompressChars2() remove single whitespace immediately
   after the non-ascii character.
(Reporter)

Comment 1

18 years ago
Created attachment 2978 [details]
Screenshot (actual result, some characters are missing)
(Reporter)

Comment 2

18 years ago
Created attachment 2979 [details]
Screenshot (expected result)
(Reporter)

Comment 3

18 years ago
Created attachment 2980 [details] [diff] [review]
Proposed patch

Updated

18 years ago
Assignee: ftang → rickg

Comment 4

18 years ago
reassign to rickg sicne the patch fix code in nsString
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: M12
(Assignee)

Comment 5

18 years ago
I have fixes in my tree, but no way to test (for this case). I'll land them and
push the bug back to you to test.
(Assignee)

Updated

18 years ago
Assignee: rickg → ftang
Status: ASSIGNED → NEW
(Assignee)

Comment 6

18 years ago
Frank -- the changes have landed. Can you retest this?

Comment 7

18 years ago
Rick,  Why don't you mark it FIXED and let QA verify this?
Teruko, Will you try to regress this?
(Reporter)

Comment 8

18 years ago
A space character between "部" and "☆" is still missing.
(Reporter)

Comment 9

18 years ago
Created attachment 3193 [details]
enlarged screenshot (actual result)
(Reporter)

Comment 10

18 years ago
Created attachment 3194 [details]
enlarged screenshot (expected result)

Comment 11

18 years ago
update the url

Updated

18 years ago
Assignee: ftang → rickg

Comment 12

18 years ago
rick, it seems your fix is not good enough. Somehow one space is missing. Mark
it FIXED if you believe you fix it and teruko, our QA, will verify it.
(Assignee)

Updated

18 years ago
Assignee: rickg → ftang
(Assignee)

Comment 13

18 years ago
Frank -- I think the bug in nsStr is fixed. There's no way for me to test this
based on the page you've provided. But if you'll provide a small test case
that's usable on a non-japanese platform I'll take another look.
(Reporter)

Comment 14

18 years ago
Created attachment 3650 [details]
non-DBCS testcase
(Reporter)

Comment 15

18 years ago
One space between alpha and 'E' is missing.
I'm not sure this would also ocuur on U.S. version sice I have only DBCS
version.

Updated

18 years ago
Assignee: ftang → rickg

Comment 16

18 years ago
Rick, I think the problem is either in nsString or in the parser code.
The following test case which will reproduce the problem in your US  window-
<HTML>
<title>a &trade;&trade; E</html>
</HTM>

there should be a space between the 2nd [TM] and E.
Notice that you have to put down even number of &trade; to reproduce this
problem.
2,4,6,8 (or any even number) of &trade; will show you the problem. 1, 3, or 5 of
them won't show you the problem.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 17

18 years ago
Frank -- thanks for being patient. The bug was not in findchar1(). It was in
compresschars2() where the logic for non-ascii chars was reversed. Fixed in my
tree awaiting approval.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

18 years ago
Fixed by update to compressChars2(). The logic for testing for valid ascii range
was reversed.

Comment 19

18 years ago
I verified this in 2000020110 M14 Win32 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.