Closed Bug 1490914 Opened 6 years ago Closed 6 years ago

Return value of encodeURIComponent() API has an error.

Categories

(Firefox :: Untriaged, enhancement)

Product:
Firefox
Component:
Untriaged
Platform:
x86
Windows 10
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: issuemaker81, Unassigned, NeedInfo)

Details

(Whiteboard: [specification][type:bug])

Attachments

(1 file)

firefox issue.png
27.42 KB, image/png
Details
What did you do? ================ 1. I using encodeURIComponent() API in Javascript for URL of browser. - encodeURIComponent('S-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6') 2. 3.  What happened? ============== Return value of FireFox is not same with Chrome, IE, Edge. '&d' string is returned as '&d' in FireFox, bug other browser is returned as '%26d'. - FIreFox : s-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6 - Chrome, IE, Edge : s-1-5-21-2521722807-1246821950-3902934973-1108%26d-92672670c6 What should have happened? ========================== Return value of encodeURIComponent('S-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6') should be 's-1-5-21-2521722807-1246821950-3902934973-1108%26d-92672670c6'. Is there anything else we should know? ====================================== This issue can be checked bellow page. https://issuemaker81.github.io/URL_Test/
In Firefox Dev Edition 63.0b4, developer tools: >> encodeURIComponent('S-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6') <- "S-1-5-21-2521722807-1246821950-3902934973-1108%26d-92672670c6" I think the issue is that your demo shows the value by loading it as a URL in another tab, and Firefox is un-escaping the URL for display in a location bar: <!DOCTYPE html> <html> <head> </head> <body> <script type = "text/javascript"> var url= encodeURIComponent('S-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6'); window.open('https://' + url, '_blank'); </script> </body> </html> Try this demo to show the value instead: <!DOCTYPE html> <html> <head> </head> <body> <p>Output of encodeURLComponent:</p> <pre id=output></pre> <script type = "text/javascript"> var url= encodeURIComponent('S-1-5-21-2521722807-1246821950-3902934973-1108&d-92672670c6'); document.getElementById('output').innerHTML = url; </script> </body> </html>
Component: API → Untriaged
OS: Other → Windows 10
Product: developer.mozilla.org → Firefox
Hardware: All → x86
Thanks for looking into this issue. We may need to provide more details about our use case that is exhibiting the problem. We are using the encodeURIComponent() function to construct a URL and set it as source of the iFrame. Please note that we used: encodeURIComponent(“S-1-5-21-2515935959-1765804235-3922288143-2135&d-92673e5c0c”) In the current Firefox version 62.0, the HTML code we got from our iframe which contains the correctly encoded user_id parameter is shown below. <iframe src="https://my_endpoint.com/api/Mydoc.docx/open?user_id=S1-5-21-2515935959-1765804235-3922288143-2135%26d-92673e5c0c" style="height: 100%;width: 100%;border: 0px;" allowfullscreen="true" allow-presentation="true" allow-popups="true" onload="iframeLoaded()"></iframe> However, though the iframe source appears to be encoded properly, our endpoint server is receiving the URL with the user_id parameter unencoded (i.e. "&" instead of "%26") as captured from the Firefox Network tab > Headers> Request URL section: https://my_endpoint.com/?open=api/abc/Mydoc.docx&user_id=S-1-5-21-2515935959-1765804235-3922288143-2135&d-92673e5c0c& We're not sure why this is happening in Firefox only and not in latest Chrome/IE.
Attached image firefox issue.png —
Hi John, As you seem to be familiar with this issue, could you please assign a component also?
Flags: needinfo?(jwhitlock)
I'm not familiar with Firefox internals, I can't assign a component. I also still think the issue is in your code. I think your bug is stuck because you've identified the problem as encodeURIComponent() having an error. However, it takes a few seconds to run some JS in the console in Firefox, Chrome, or another browser, and see that the output is exactly the same. A bug in encodeURIComponent would be very important, but it looks like the issue is elsewhere in the code that hasn't been shared. When you do identify the root cause, you may want to open a new bug with a different title - stale bugs tend to stay stale. You state that this is correctly encoded: <iframe src="https://my_endpoint.com/api/Mydoc.docx/open?user_id=S1-5-21-2515935959-1765804235-3922288143-2135%26d-92673e5c0c" ...> This is the encoding for this URL: https://my_endpoint.com/api/Mydoc.docx/open?user_id=S1-5-21-2515935959-1765804235-3922288143-2135&d-92673e5c0c This reads as "GET /api/Mydoc.docx/open with 2 parameters, user_id=S1-5-21... and d-92673e5c0c=<no value> It is unclear how it becomes this: https://my_endpoint.com/?open=api/abc/Mydoc.docx&user_id=S-1-5-21-2515935959-1765804235-3922288143-2135&d-92673e5c0c& I'd expect that is your server issuing a redirect, or JavaScript code manipulating the URL before it is sent. Something like this might work as the value for <iframe src=...>: https://my_endpoint.com/api/Mydoc.docx/open?user_id=S1-5-21-2515935959-1765804235-3922288143-2135%2526d-92673e5c0c This double-encodes the parameter (encodeURIComponent(encodeURIComponent(“S-1-5-21-2515935959-1765804235-3922288143-2135&d-92673e5c0c”)), turning the '&' into '%26' and then into '%2526'. It's possible that if you view source on the HTML (not the processed and pretty-printed version in development tools inspector) that there is a double encoding in Chrome and IE and a single encoding in Firefox. You'll need to look at the code that creates that HTML. I find URL encoding to be tricky, and avoid using reserved characters in parameters. An underscore (_) or other letter (X, Z) instead of an ampersand (&) would give you less grief, if you control the frontend or backend.
Flags: needinfo?(jwhitlock)
Hi issuemaker81, Could you give us some feed back on comment 5 ?
Flags: needinfo?(issuemaker81)
Marking this as Resolved: Incomplete due to the lack of response from the reporter. If the issue is still reproducible with the latest Firefox version, feel free to reopen the bug with more information.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: