btoa only works with ISO-8859-1

RESOLVED INVALID

Status

()

Core
Internationalization
--
major
RESOLVED INVALID
14 years ago
2 years ago

People

(Reporter: smontagu, Assigned: smontagu)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

14 years ago
The btoa() function currently fails with NS_ERROR_DOM_INVALID_CHARACTER_ERR if
the input (in UTF-16) contains characters outside the range of ISO-8859-1, even
if all the characters are single-byte in the encoding of the page.

I think we should be converting the input to the page charset and then
converting to base64, just as we do for escape().

Comment 1

9 years ago
Created attachment 343605 [details]
Test encoding non-ISO-8859-1 strings

Updated

9 years ago
Duplicate of this bug: 439711
(Assignee)

Comment 3

9 years ago
-> major per bug 439711 comment 3
Severity: normal → major
What does it do in other UAs?  Will changing behavior here break any webpages?

Comment 5

9 years ago
He made it major due to how completely useless btoa is for user input and if it is fixed then extenion developers don't need to make their own Base64 encoding function.
(Assignee)

Comment 6

9 years ago
Attachment 343605 [details] fails in Safari also. 

My original suggestion in comment 0 to convert the input to the page encoding is not foolproof, since user input can easily include characters not representable in the page encoding. Maybe a better solution is to explicitly convert the input to UTF-8 before calling btoa?
If we're talking about extensions then we don't need to necessarily change the web-facing btoa.  We could provide an XPCOM API for doing this instead.

This bug is about web-facing btoa.  If we need a separate bug for extensions (based on the conclusions reached in this bug), so be it.

My gut feeling is that the suggestion in the last sentence of comment 6 will break sites (any site that is ISO-8859-1 and that does conversion one way on the client and the other on the server, for example!), but I eagerly await a decent analysis of IE's behavior (ideally IE7/quirks, IE7/standards, IE8/standards, in case they differ) here.  That will give us a good starting point for what web sites expect.
(Assignee)

Comment 8

9 years ago
(In reply to comment #7)

> My gut feeling is that the suggestion in the last sentence of comment 6 will
> break sites

Then you misunderstood it: I meant that even if we didn't change any code, the extension developer could do the conversion before calling btoa.
QA Contact: amyy → i18n
Wontfix?
I'm really confused about this. The API is called "btoa". binary to ascii.

So by definition, shouldn't it be able to take any binary data? Why is certain data not allowed?

In particular, I don't understand why this doesn't work:

btoa("Firefox Hello — Join the conversation");

Yet if I go to any base 64 encoder, it properly encodes to:

RmlyZWZveCBIZWxsbyDigJQgSm9pbiB0aGUgY29udmVyc2F0aW9u

What am I missing?
https://html.spec.whatwg.org/multipage/#dom-windowbase64-btoa

Changes to this API can be discussed in all the usual venues for that spec, which does not include this bugzilla instance.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.