Closed
Bug 125621
Opened 23 years ago
Closed 19 years ago
Display non-ASCII characters in paths in file-type HTML input form fields
Categories
(Core :: Internationalization, defect, P1)
Tracking
()
RESOLVED
WORKSFORME
mozilla1.2final
People
(Reporter: mozilla.org, Assigned: alecf)
References
()
Details
(Keywords: intl, regression)
Attachments
(1 file)
15.19 KB,
image/png
|
Details |
input type=file form controls interpret non-ASCII filenames incorrectly using
build 2002021303 on Mac OS X 10.1.2.
To reproduce:
1. Create a file called é.txt
2. Choose Create a New Attachment in Bugzilla to attempt to attach the file to
this bug report.
The path should appear in the form field as é.text, but it appears as e´.txt.
Keywords: mozilla0.9.9,
regression
This problem first appears in build 2002020103. The problem does not occur in
build 2002013108.
Keywords: mozilla0.9.9 → mozilla1.0
Updated•22 years ago
|
QA Contact: madhur → tpreston
Confirmed using FizzillaCFM/2002041712 (RC1). The path works, as the file does
get uploaded, but it's not displayed right.
Guessing Internationalization, as this is probably dependent on some of the
internal UTF conversion work going on.
Assignee: rods → yokoyama
Severity: major → minor
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Internationalization
Ever confirmed: true
QA Contact: tpreston → ruixu
Summary: non-ASCII path interpreted incorrectly by input type=file → Display non-ASCII characters in paths in file-type HTML input form fields
Comment 4•22 years ago
|
||
please attach a screen shot of the problem
screen shot of problem:
attaching file "Macintosh HD:é:screen.png"
path displayed in form input field as "Macintosh HD:e´:screen.png"
Comment 6•22 years ago
|
||
This looks caused by
mac side of fix for bug 100676
on mozilla/ xpcom/ io/ nsLocalFileMac.cpp
1.93alecf%netscape.comJan 31 13:54
Assignee: yokoyama → alecf
Assignee | ||
Comment 7•22 years ago
|
||
not sure what went wrong here either. again, is this mac-only or is this also
visible on windows?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Assignee | ||
Comment 8•22 years ago
|
||
are we still seeing this problem? nsLocalFile has changed quite a bit lately.
I've just walked through the code myself and I think this was fixed when darin
switched us over to a UCS2 api.
see
http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsFileControlFrame.cpp#319
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
This is not fixed yet. I still have this problem with 1.1beta on Mac OS X
10.1.5. Please refer to the steps to reproduce listed above.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 10•22 years ago
|
||
thanks for re-testing.. I'll have to do more investigation.
Status: REOPENED → ASSIGNED
Priority: -- → P2
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Assignee | ||
Updated•22 years ago
|
Priority: P2 → P1
Assignee | ||
Comment 11•22 years ago
|
||
moving some stuff out to mozilla1.2beta that didn't make the mozilla1.2alpha train
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Reporter | ||
Comment 12•22 years ago
|
||
This works properly in Mozilla 1.1 on Mac OS X 10.2. It may be an OS bug in Mac
OS X 10.1.
Assignee | ||
Comment 13•22 years ago
|
||
ah! ok I'm going to remark worksforme then. Thanks for re-testing again :)
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 14•22 years ago
|
||
It is still reproducible with NS7.0 and 091708 trunk on MacOS X 10.2 and MacOS
X 10.1.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 15•22 years ago
|
||
Is this going to make 1.2final?
Assignee | ||
Comment 16•22 years ago
|
||
I'm going to try... we'll see.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.2beta → mozilla1.2final
Comment 17•22 years ago
|
||
This may be a quirk in the Mac OS, both Classic and OS X. I followed the steps
to check the testcase. Under OS 9.2.2, I cannot seem to save a file of that
name, using SimpleText. The filename defaults to what one sees in the
screenshot. Unless, of course, I've screwed up somehow. I'll have to try using
another program, but I think SimpleText is as good as anything for creating a
testcase sample.
Oh yes, the build of Mozilla I'm using is 2002103008.
Reporter | ||
Comment 19•19 years ago
|
||
Works in Mozilla 1.7.8
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•