675141 - Jetpack modules should be able to use btoa() and atob()

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, enhancement, P1)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

+++ This bug was initially created as a clone of Bug #656037 +++

This bug is specifically for adding/exposing btoa() and atob() functions. Bug 656037 can carry on as a meta-bug for any other window-scoped functions that should be made global.

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Marking anything that potentially looks like a feature request as "enhancement", sorry for the bugspam. :)

Comment 2

[David Chan [:dchan]]

Is there more to the bug than

var data = require("api-utils/utils/data");
data.base64Decode("string");


This would end up using one of the internal addon-sdk libraries but it is built on top of btoa and atob [1]

There would still need to be a wrapper to handle utf-8 strings as mentioned on MDN [2]

[1] - https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/lib/utils/data.js#L97
[2] - https://developer.mozilla.org/en/DOM/window.btoa

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

There is no more to the bug than adding wrappers for those functions into addon-kit somewhere that makes sense that are safe and also transparently account for utf-8 strings without the user needing to know the gory details:

https://builder.addons.mozilla.org/library/1014117/revision/4/

IMO an important goal for something in the addon-kit api would be to ensure that users can use a module with confidence and not have to worry about utf-8.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Actually, I believe this bug is about adding atob and btoa functions as globals to the scopes of modules by default, to make such scopes more like the web page scopes with which developers are familiar, as part of our effort to hug the web harder <https://wiki.mozilla.org/Features/Jetpack/Make_Add-on_SDK_Hug_the_Web_Harder>.

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Myk: that would totally work too, and in that case I guess the best approach would be to *not* implement a wrapper that attempts utf-8 handling, as btoa and atob don't do this in web page scopes.

Comment 6

[Alexandre Poirot [:ochameau]]

It can be fixed really easily but it seems that ES.next doesn't plan to expose those methods in harmony modules, so that it doesn't make sense to expose them in globals.
So should with mark this bug as wontfix?

Irakli, do you have some links about this es.next decision?

Comment 7

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I'm afraid there are no links to ES discuss, but you probably can get some hints by looking at proposals

http://wiki.ecmascript.org/doku.php?id=harmony:modules
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

Comment 8

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Attachment: Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/454

Pointer to Github pull-request

Comment 9

[Alexandre Poirot [:ochameau]]

Comment on attachment 627414 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/454

This issue has been fixed by this changeset:
https://github.com/mozilla/addon-sdk/commit/3330c3eb5e20c9bbae2d1a516ddb6324387b6078
We now have a new module:
  require("api-utils/base64").encode/decode

Comment 10

[Alexandre Poirot [:ochameau]]

As said in comments 6/7 it may not be a good idea to expose atob and btoa in global scope in order to better match coming harmony module standard.

Feel free to reopen this bug if you think otherwise.