Closed Bug 155199 Opened 22 years ago Closed 22 years ago

functions calls with %-encoded parameters fail in HTML-links

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 137182

People

(Reporter: arne, Assigned: jst)

References

(
URL
)

Details

Attachments

(1 file)

Reporter's testcase
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.
Browser, not engine ---> DOM Level 0
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale
Attached file Reporter's testcase — 

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
Bug 137182 is the reason for characters outside the ASCII range not working in
javascript: URL's.

    
    

    
  
What is left to do here?  All the testcases work as expected as far as I can tell...

    
    

    
  
Nothing, as far as I can tell. It was left open for the i18n issues, dealt with
in bug 137182. 

    
    

    
  
ok

*** This bug has been marked as a duplicate of 137182 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: