Closed Bug 66042 Opened 24 years ago Closed 22 years ago

Status bar is incorrectly shown when DBCS filename loaded

Categories

(Core :: Networking: File, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: m_kato, Assigned: nhottanscp)

Details

(Keywords: intl)

Attachments

(6 files)

STEP
====
1. Open Navigator
2. D&D DBCS filename to Mozilla window

RESULT
======
DBCS filename is incorrectly shown on Status bar.
Attached image screenshot
Kato san, can this be done by using nsILocalFile instead of adding new
conversion code?
OK.  I try it.
Assignee: dougt → m_kato
Marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch, review
I tried that changing name property to wstring in nsIStreamIO.
But stack overflaw occurs since it uses this property when nsILocalFile gets
nsIPlatformCharset.  So this fix may not be smart.
Do you mean nsIPlatformCharset depends on nsFileTransport?
Yes.  nsFileTransport::Init function is called when it creates nsIPlatformCharset.
Please contact Frank Tang for this.
Frank, why nsIPlatformCharset depends on nsFileTransport?


Keywords: intl
Your first patch use nsIPlatformCharset also, right ?
I think the problem is nsILocalFile but not nsIPlatformCharset, right ?
make sense by stack trace??
Of course, If you change nsIStreamIO::name property to wstring, the same problem
occurs.

So I think that workaround fix will be better.

0:000> k 40
ChildEBP RetAddr
00033188 77fb3edb ntdll!RtlAllocateHeapSlowly+0x25
0003320c 77fa5f7c ntdll!RtlDebugAllocateHeap+0xcb
000333dc 77fcabba ntdll!RtlAllocateHeapSlowly+0x5a
00033584 1020de9c ntdll!RtlAllocateHeap+0x808
000335c0 10212c12 MSVCRTD!_heap_alloc_base+0x13c [malloc.c @ 200]
000335e8 102129f9 MSVCRTD!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
00033628 10212949 MSVCRTD!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
00033648 3000bc6d MSVCRTD!malloc+0x19 [dbgheap.c @ 130]
00033654 1001e850 nspr4!PR_Malloc+0xd
00033670 1001ef06 xpcom!nsMemoryImpl__Alloc+0x10
00033680 010c546b xpcom!nsMemory__Alloc+0x26
000336a4 010bf798 necko!ExtractURLScheme+0xc
000336bc 010bf806 necko!nsIOService__ExtractScheme+0x18
00033700 010bf939 necko!nsIOService__NewURI+0x66
00033718 012bd59e necko!nsIOService__NewURI+0x19
00033798 012bb1e9 uconv!nsURLProperties__nsURLProperties+0xae
000338f0 012bb65f uconv!nsWinCharset__nsWinCharset+0x48
00033914 100697d5 uconv!NS_NewPlatformCharset+0x4a
00033928 10064ea4 xpcom!nsGenericFactory__CreateInstance+0x15
00033954 1006f103 xpcom!nsComponentManagerImpl__CreateInstance+0x74
00033978 10068c68 xpcom!nsComponentManager__CreateInstance+0x43
000339e8 100690c7 xpcom!nsServiceManagerImpl__GetService+0x108
00033a18 100693b3 xpcom!nsServiceManagerImpl__GetService+0x47
00033a3c 100682a7 xpcom!nsServiceManager__GetService+0x43
00033a60 1004abab xpcom!nsGetServiceByContractID__operator()+0x67
00033a78 1004a742
xpcom!nsCOMPtr<nsIPlatformCharset>__assign_from_helper+0x1b
00033a8c 10051e1f
xpcom!nsCOMPtr<nsIPlatformCharset>__nsCOMPtr<nsIPlatformCharset>+0x22
00033abc 10052056 xpcom!nsFSStringConversion__PrepareFSCharset+0x1e
00033ae0 10052262 xpcom!nsFSStringConversion__PrepareDecoder+0x26
00033af4 10052556 xpcom!nsFSStringConversion__FSToNewUCS+0x12
00033b0c 010cee49 xpcom!nsLocalFile__GetUnicodePath+0x30
00033b68 010cea7d necko!nsFileTransport__Init+0x139
00033b90 010be6b7 necko!nsFileTransport__Init+0x7d
00033bb8 01121d9f necko!nsFileTransportService__CreateTransport+0x67
00033c38 01122004 necko!nsFileChannel__EnsureTransport+0x9f
00033c48 0112c615 necko!nsFileChannel__OpenInputStream+0x24
00033c60 012bd8c2 necko!nsResChannel__OpenInputStream+0x85
00033c90 012bd5d4 uconv!NS_OpenURI+0x92
00033d20 012bb1e9 uconv!nsURLProperties__nsURLProperties+0xe4
00033e78 012bb65f uconv!nsWinCharset__nsWinCharset+0x48
00033e9c 100697d5 uconv!NS_NewPlatformCharset+0x4a
00033eb0 10064ea4 xpcom!nsGenericFactory__CreateInstance+0x15
00033edc 1006f103 xpcom!nsComponentManagerImpl__CreateInstance+0x74
00033f00 10068c68 xpcom!nsComponentManager__CreateInstance+0x43
00033f70 100690c7 xpcom!nsServiceManagerImpl__GetService+0x108
00033fa0 100693b3 xpcom!nsServiceManagerImpl__GetService+0x47
00033fc4 100682a7 xpcom!nsServiceManager__GetService+0x43
00033fe8 1004abab xpcom!nsGetServiceByContractID__operator()+0x67
00034000 1004a742
xpcom!nsCOMPtr<nsIPlatformCharset>__assign_from_helper+0x1b
00034014 10051e1f
xpcom!nsCOMPtr<nsIPlatformCharset>__nsCOMPtr<nsIPlatformCharset>+0x22
00034044 10052056 xpcom!nsFSStringConversion__PrepareFSCharset+0x1e
00034068 10052262 xpcom!nsFSStringConversion__PrepareDecoder+0x26
0003407c 10052556 xpcom!nsFSStringConversion__FSToNewUCS+0x12
00034094 010cee49 xpcom!nsLocalFile__GetUnicodePath+0x30
000340f0 010cea7d necko!nsFileTransport__Init+0x139
00034118 010be6b7 necko!nsFileTransport__Init+0x7d
00034140 01121d9f necko!nsFileTransportService__CreateTransport+0x67
000341c0 01122004 necko!nsFileChannel__EnsureTransport+0x9f
000341d0 0112c615 necko!nsFileChannel__OpenInputStream+0x24
000341e8 012bd8c2 necko!nsResChannel__OpenInputStream+0x85
Ftang - Please assigned priority and milestone.
Ftang - Is this fixed??? If so, please close, so we can take it off our radar.
Status: NEW → ASSIGNED
not fix, yet.  I re-try this.
Cc to yokoyama, he recently fixed a file url related bug.
can someone verify this is the right component? I am cleaning the QA assignments 
for "file".
QA Contact: tever → benc
RC1 review: Please target this bug and answer my previous question.
QA Contact: benc → nobody
I think this was fixed after we use UTF-8 for internal URI.
Assignee: m_kato → nhotta
Status: ASSIGNED → NEW
QA Contact: nobody → ylong
I think this was fixed after we use UTF-8 for internal URI.

Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Can not reproduce the original problem on latest trunk build, mark as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: