User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 When btoa is passed a string containing unicode such as "→", which is used in the example, it produces the error "String contains an invalid character". It should not do this as it outputs utf-8 base64 strings. It should behave mostly like the non-native implementation I have in the example. This is very important to work when someone is using btoa to base64 encode user-input which can result in lost data. Reproducible: Always Steps to Reproduce: 1. Pass btoa some unicode characters. Actual Results: I get the "String contains an invalid character" error. Expected Results: I get the base64 encoded equivalent of the string.
This could actually be a bug in NSPR, if it is legit. Moved to DOM for now, though.
Easily recreated. I'd like to flag this bug as "important" as btoa is useless for encoding user input. I've had to fall back to using encodeURIComponent instead.
This bug should be either fixed now or the btoa/atob functions be removed from the codebase until it can be fixed. I am using these functions as part of encryption scheme in an extension I released. I was unaware of the problem until I started to receive negative feedback. A function that works only part of the time is worse than one that doesn't work at all.
Added a new testcase that also gives the error and output of btoa in an alert message and tells if btoa worked.
Attachment #325444 - Attachment is obsolete: true
Moved to major for reason of comment #3 and removed url that I didn't really need to have there.
Severity: normal → major
This looks like a duplicate of bug 213047
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 213047
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.