Closed
Bug 92109
Opened 23 years ago
Closed 4 years ago
Status bar string variables unable to handle non-Ascii characters
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: annac, Assigned: nhottanscp)
References
Details
(Keywords: intl)
When a search is completed from the location bar, the text in the status bar
changes to 'Resolving host' and then a variable - in this case the search
word(s). If the search string contains extended characters they are now
incorrectly displayed in the status bar. i.e. they appear corrup
steps to repro:
1. In the Location bar type in a word that contains extended characters i.e. M�«änich
2. Click on Search
3. Note the text in the status bar
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 1•23 years ago
|
||
cc to IQA
Comment 3•23 years ago
|
||
Actually I input a Japanese or Chinese characters in URL location bar then press
the "enter", the status bar will appears garbage after the string "Resolving
host". - I saw it on both Win2k-CN and WinXP-Ja with today's branch build.
Should we change to "unable to handle non-Ascii characters" in Summary?
Not reproduce on Mac and Linux.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 4•23 years ago
|
||
Changing summary accordingly to Yuying's suggestion.
Keywords: intl
Summary: Status bar string variables unable to handle extended characters → Status bar string variables unable to handle non-Ascii characters
Comment 5•23 years ago
|
||
I have another case:
If I open a file which saved under a non-ascii(Japanese, chinese ..etc)
folder or file name though browser File | Open File, then the status bar
will display garbage as well, I saw it on Win2k-CN, Mac9.0-Ja and
RedHat6.2-Ja, but on WinME-Ja and WinXP-Ja, the non-ascii path / file
name will show number code like: %C8%D5%B1%BE.
Change Platform to All.
OS: Windows NT → All
Hardware: PC → All
Comment 6•23 years ago
|
||
Encoded string is displayed as "???" in status bar.
Maybe this is the same problem.
http://dmoz.org/World/Japanese/%a5%b3%a5%f3%a5%d4%a5%e5%a1%bc%a5%bf/%a5%bd%a5%d5%a5%c8%a5%a6%a5%a7%a5%a2/%a5%a4%a5%f3%a5%bf%a1%bc%a5%cd%a5%c3%a5%c8/%a5%d6%a5%e9%a5%a6%a5%b6/Mozilla/
Comment 8•23 years ago
|
||
move to jbetak and mark m9.4
Assignee: nhotta → jbetak
Status: ASSIGNED → NEW
Keywords: nsBranch
Whiteboard: nsbranch+
Target Milestone: --- → mozilla0.9.4
Comment 9•23 years ago
|
||
Per Selmer suggestion, I am doing this myself.
Moving nsbranch+ designation from the Status Whiteboard to Keywords.
Comment 10•23 years ago
|
||
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
Comment 11•23 years ago
|
||
remove nsbranch+ keyword. move to m0.9.6
Comment 12•23 years ago
|
||
nsbranch- since Frank moved it to 0.9.6
Comment 13•23 years ago
|
||
pushing our a bit and accepting...
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 14•23 years ago
|
||
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → ---
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.2
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Assignee | ||
Comment 16•22 years ago
|
||
The test data in comment #6 works when the document charset is set to "EUC-JP".
The problem is the original report requires IDN (International Domain Name) support.
Depends on: 112979
Target Milestone: mozilla1.2beta → ---
Updated•15 years ago
|
QA Contact: ruixu → i18n
Updated•4 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•