66042 - Status bar is incorrectly shown when DBCS filename loaded

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[Makoto Kato [:m_kato]]

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

RESULT
======
DBCS filename is incorrectly shown on Status bar.

Comment 1

[Makoto Kato [:m_kato]]

Attachment: screenshot

Comment 2

[Makoto Kato [:m_kato]]

Attachment: fix at 2001/01/20

Comment 3

[nhottanscp]

Kato san, can this be done by using nsILocalFile instead of adding new
conversion code?

Comment 4

[Makoto Kato [:m_kato]]

OK.  I try it.

Comment 5

[Keyser Sose]

Marking NEW

Comment 6

[Makoto Kato [:m_kato]]

Attachment: fix at 2001/01/27

Comment 7

[Makoto Kato [:m_kato]]

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.

Comment 8

[nhottanscp]

Do you mean nsIPlatformCharset depends on nsFileTransport?

Comment 9

[Makoto Kato [:m_kato]]

Yes.  nsFileTransport::Init function is called when it creates nsIPlatformCharset.

Comment 10

[nhottanscp]

Please contact Frank Tang for this.
Frank, why nsIPlatformCharset depends on nsFileTransport?

Comment 11

[Frank Tang]

Your first patch use nsIPlatformCharset also, right ?
I think the problem is nsILocalFile but not nsIPlatformCharset, right ?

Comment 12

[Makoto Kato [:m_kato]]

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

Comment 13

[Jaime Rodriguez, Jr.]

Ftang - Please assigned priority and milestone.

Comment 14

[Jaime Rodriguez, Jr.]

Ftang - Is this fixed??? If so, please close, so we can take it off our radar.

Comment 15

[Makoto Kato [:m_kato]]

not fix, yet.  I re-try this.

Comment 16

[nhottanscp]

Cc to yokoyama, he recently fixed a file url related bug.

Comment 17

[Makoto Kato [:m_kato]]

Attachment: a patch at 2001/07/08

Comment 18

[Makoto Kato [:m_kato]]

Attachment: a patch at 2001/0708 part 2 since prev patch is mistake

Comment 19

[Makoto Kato [:m_kato]]

Attachment: a patch (mozilla/dom side) at 2001/07/08

Comment 20

[benc]

can someone verify this is the right component? I am cleaning the QA assignments 
for "file".

Comment 21

[benc]

RC1 review: Please target this bug and answer my previous question.

Comment 22

[nhottanscp]

I think this was fixed after we use UTF-8 for internal URI.

Comment 23

[nhottanscp]

I think this was fixed after we use UTF-8 for internal URI.

Comment 24

[Yuying Long]

Can not reproduce the original problem on latest trunk build, mark as verified.