Closed Bug 125223 Opened 23 years ago Closed 23 years ago

Can't handle non-ASCII characters in URI

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mori3, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: intl, regression) 

BuildID: 2002021203
OS: Windows XP/2000 Japanese

Even if it clicks URL (link) which Japanese is contained,
it is not displayed well.
I think the bug of conversion of a character code.
Moziila 0.9.8 is no problem.

Reproducible: Always
Steps to Reproduce:
1.jump to this url
    http://jpstore.dell.com/store/newstore/soho/desktop_express.asp
2.click 'desktop OptiPlex' or 'desktop DIMENSION' url(link) containing Japanese

Actual Results:  Nothing happens

Ideal Results:  Each item should be displayed.
got 2002021203, too - WinXP (US) - i DO see the problem, but it's _not_ a
_general_ bug with a URL containing japanese, since some other links containing
it do work. i checked, it's not a problem with the server, IE does the job.
I have this problem to: Windows XP build 2002021303.  Could it be due to the
escaping of characters:
http://jpstore.dell.com/store/newstore/soho/desktop_express.asp?catalog=%C2%83f%C2%83X%C2%83N%C2%83g%C2%83b%C2%83v%20OptiPlex
Confirming. It is OK to use extended characters in the name-value arguments,
just as it would be for a form using the GET method. However, this could be
happening because the script isn't properly handling the escaped characters.
Looks like it might be an evangelism issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: blocker → normal
W3C spec:
http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars

Changing Component and Summary.
Component: Browser-General → Internationalization
OS: Windows XP → All
Summary: URL containing Japanese is not displayed well → Can't handle non-ASCII characters in URI
Keywords: intl
4.7x also can work.
-> nsbeta1
Keywords: nsbeta1
Can also repro it with trunk build 2002-02-21.
Does this work on NS6.2 and broken in the trunk?
Yes, it works on N6.2.1/WinXP-CN.
Keywords: regression
The regression happens sometime between 01-18 and 01-31 trunk build.
cc to darin

Non ASCII URI handling will change by bug 124042 which may affect this bug.
Darin, is there win32 build available with the patch of bug 124042?
Assignee: asa → nhotta
>The regression happens sometime between 01-18 and 01-31 trunk build.
Darin, any idea about this?


i'm not sure what might have caused the regression... let's see what the fix for
bug 124042 yields.
Yuying, could you try the darin's win32 build?
That windows build works fine.
Thanks for the testing. Let's make it depends on bug 124042.
Depends on: 124042
Tested on Linux with Darin's patch in bug 124042 applied, works fine.
nsbeta1+ per i18n triage
Keywords: nsbeta1 → nsbeta1+
It works fine on 03-06 trunk build/WinME-JA and Mac OS X.
Reassign to darin.
Assignee: nhotta → darin
Fixed in the trunk by bug 124042.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.0
re-assigning qa contact. Yuying, could you, please see if it works now? Thanks.
QA Contact: doron → ylong
Mark it works fine on 06-10 1.4 branch build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.