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)

defect
Not set
normal

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
cc to IQA
Switching qa contact to jonrubin.
QA Contact: andreasb → jonrubin
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.
Status: NEW → ASSIGNED
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
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
*** Bug 94803 has been marked as a duplicate of this bug. ***
move to jbetak and mark m9.4
Assignee: nhotta → jbetak
Status: ASSIGNED → NEW
Keywords: nsBranch
Whiteboard: nsbranch+
Target Milestone: --- → mozilla0.9.4
Per Selmer suggestion, I am doing this myself. Moving nsbranch+ designation from the Status Whiteboard to Keywords.
Keywords: nsbranchnsbranch+
Whiteboard: nsbranch+
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
remove nsbranch+ keyword. move to m0.9.6
Keywords: nsbranch+nsbranch
Target Milestone: mozilla0.9.4 → mozilla0.9.6
nsbranch- since Frank moved it to 0.9.6
Keywords: nsbranchnsbranch-
pushing our a bit and accepting...
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 107067
Keywords: nsbranch-
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
give to nhotta to research
Assignee: ftang → nhotta
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → mozilla1.2
No longer blocks: 107067
Target Milestone: mozilla1.2alpha → mozilla1.2beta
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 → ---
QA Contact: ruixu → i18n
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.