Closed
Bug 155199
Opened 23 years ago
Closed 23 years ago
functions calls with %-encoded parameters fail in HTML-links
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 137182
People
(Reporter: arne, Assigned: jst)
References
()
Details
Attachments
(1 file)
257 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID: 2002053012
When a string with %-encoded characters (such as %e4%f6%fc%df (= הצ��, german
characters)) is used as parameter in a function call this function call fails.
<a href="javascript:foo('%e4%f6%fc%df');">call foo</a>
does not work
Reproducible: Always
Steps to Reproduce:
1. Create a function showing the given parameter: foo(x) { alert(x); }
2. Call this function via HTML-Link with a parameter like <a
href="javascript:foo('%e4%f6%fc%df');">call foo</a>
3. The call fails
Actual Results: Nothing happens.
Expected Results: The function should be called and show the parameters.
Example file:
<html>
<head>
<script type="text/javascript" language="JavaScript">
function foo(value) { alert(value); }
</script>
</head>
<body>
<a href="javascript:foo('%e4%f6%fc%df');">call foo('%e4%f6%fc%df')</a>
</body>
</html>
____
On every other of my browsers (IE5.0, NN4.75, Opera6.03, all on Win98) it works.
Comment 1•23 years ago
|
||
Browser, not engine ---> DOM Level 0
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
Confirming bug with Mozilla trunk binary 20020617xx on WinNT.
In IE6, you get the alert of German letters when you click on
the link in the testcase. In Mozilla, no alert comes up.
No errors are reported in the JavaScript Console. Is this related to
bug 137182, "javascript: URL's with non-UTF-8 characters not working" ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•23 years ago
|
||
OOPS, my Comment #1 was necessary above. The reporter has provided
a more complete testcase in the URL field above:
http://arnep.de/temp/mozilla-bug-test.htm
Comment 5•23 years ago
|
||
Does this work on any older build? Like before the checkin for bug 104081? I
thought that checkin would have fixed this... Or has it regressed since?
Comment 6•23 years ago
|
||
We unescape the whole javascript url, if you want encoded strings to survive in
the url before given to the javascript engine then mask them, in this case:
<a href="javascript:foo('%25e4%25f6%25fc%25df');">call foo('%e4%f6%fc%df')</a>
The link <a href="javascript:alert('%80');">alert('')</a> does not work. No value greater than Hex %7F (=ASCII 127) seems to be allowed. All other Browsers do allow it.
Comment 8•23 years ago
|
||
Arne, again try to mask the % in encoded characters as %25 if you want this to
survive the unescape.
Thanks for help, it now works!
Masking with %25 helps and works with Moz and IE, but on Opera and NN4.75 the de-masking does not really work, both of them show "%25e4%25f6%25fc%25df" where the others show "%e4%f6%fc%df" (Moz) or "הצ��" (IE5.0).
I think I will use a browser-sniffer.
Still, the problem it not solved, it is just a work-around.
Comment 10•23 years ago
|
||
This is the way it has to be, this is how urls work. % is a operator in
javascript, but % is also the encoding character in urls, so by definition
javascript urls need escaping, so before given to the javascript engine they
have to be unescaped. Unescaping is global, so you have to mask all your % you
want to survive, even as part of strings, unescaping does not and will not know
strings.
I think there are a lot of javascript urls that will fail in Opera and NS4.x
because of this missing unescape. I my opinion it is fixed with mozilla.
Assignee | ||
Comment 11•23 years ago
|
||
Bug 137182 is the reason for characters outside the ASCII range not working in
javascript: URL's.
![]() |
||
Comment 12•23 years ago
|
||
What is left to do here? All the testcases work as expected as far as I can tell...
Comment 13•23 years ago
|
||
Nothing, as far as I can tell. It was left open for the i18n issues, dealt with
in bug 137182.
![]() |
||
Comment 14•23 years ago
|
||
ok
*** This bug has been marked as a duplicate of 137182 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•