Last Comment Bug 123003 - window.atob and window.btoa are not implemented
: window.atob and window.btoa are not implemented
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: mozilla0.9.9
Assigned To: Johnny Stenback (:jst,
: Prashant Desale
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2002-02-01 10:24 PST by Georg Maaß
Modified: 2002-02-05 20:43 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Proposed fix. (4.64 KB, patch)
2002-02-01 19:22 PST, Johnny Stenback (:jst,
no flags Details | Diff | Splinter Review
Same as above, but w/o the leaks. (4.46 KB, patch)
2002-02-04 18:11 PST, Johnny Stenback (:jst,
no flags Details | Diff | Splinter Review
Er, that wasn't right, but this should be... (4.58 KB, patch)
2002-02-04 18:53 PST, Johnny Stenback (:jst,
bzbarsky: review+
Details | Diff | Splinter Review
More understandable patch, same as above, just renaming things a bit... (4.86 KB, patch)
2002-02-05 18:01 PST, Johnny Stenback (:jst,
bzbarsky: review+
jst: superreview+
Details | Diff | Splinter Review

Description Georg Maaß 2002-02-01 10:24:00 PST
window.atob and window.btoa are not implemented. I would prefer them as parts of
the jsengine, but Brendan E. prefers them to reside inside the host implementation.
Comment 1 Alfonso Martinez 2002-02-01 16:01:04 PST
Confirming in Build 2002013003, win98 ->OS All
Comment 2 Johnny Stenback (:jst, 2002-02-01 19:22:17 PST
Created attachment 67553 [details] [diff] [review]
Proposed fix.
Comment 3 Johnny Stenback (:jst, 2002-02-01 19:23:37 PST
Bz, Brendan, reviews?
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2002-02-01 20:02:49 PST
Comment on attachment 67553 [details] [diff] [review]
Proposed fix.

You're leaking |base64| and |ascii| in both those functions on success.
You want to free them.

Also, I don't think you need the resultLen stuff.  I assume the data channel
just does this because it's faster than an implicit strlen (which is
what the nsDependentCString you use in Atob does).  I'd just
use the dependent CString for both.

Finally, is there something somewhere that explains exactly what
atob and btoa should be doing?	Georg?
Comment 5 Brendan Eich [:brendan] 2002-02-02 02:00:38 PST and below
provide source for the Classic atob and btoa.

Comment 6 Johnny Stenback (:jst, 2002-02-02 02:03:26 PST
Er, duh, silly leaks!

I do need resultLen since there can be embedded nulls encoded in the base64
encoded string that comes into btoa(), strlen() would give the wrong answer in
such a case.

The implicit strlen() in atob() is fine since the string is base64 encoded at
that point and will not contain nulls even if the ascii string that came in to
atob() contained embedded nulls.
Comment 7 Johnny Stenback (:jst, 2002-02-02 02:05:27 PST
Brendan, yes, but that code uses ATOB_AsciiToData() (n' friend), which according
to lxr always return null (?), see
Comment 8 Georg Maaß 2002-02-02 07:31:48 PST
It enables me to decode via JavaScript data that has been encoded  i.e by PHP
using base64_encode or to encode data with JavaScript, to decode it on the
server with PHP using base64_decode. In stead of PHP on server side there might
also be a JavaScript capable server, which sould also implement that functions.
This is the reasons, whay I sugessted them to become part of the langauge
instead of the host object.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2002-02-02 08:54:18 PST
OK.  I was just asking because btoa is apparently an algorithm in its own right
distinct from uuencode and base64 (except in Navigator, apparently)...

jst, wouldn't it make more sense to change PL_Base64Decode to return the length
(as ATOB_AsciiToData does)?  That way all its callers won't have to copy the
length-calculation code....
Comment 10 Georg Maaß 2002-02-02 09:04:48 PST
I must confess, that I do not really know how the algorithm works. I just know
that the implementation of atob an btoa is compatible to the Code generated by
PHP. I used it to code images to be displayed via javascript:atob('encoded
stuff') inside scr attributes. We also used it as a very simple mechanism of
making stuff unreadable to human eyes (very primitive kind of encryption). In
such applications i used the atob an btoa functions for diagnosis ond
manipulation purposes on client side to debug such applications.
Comment 11 Brendan Eich [:brendan] 2002-02-02 14:20:29 PST
jst, sorry -- I should have followed that link.  It dangles because
ATOB_AsciiData was for some silly reason obfuscated or stubbed out along with a
bunch of classic crypto code.  I found descendents of the old code at and above -- I
trust these preserve all the semantics.  Cc'ing relyea.

Comment 12 Johnny Stenback (:jst, 2002-02-02 14:36:47 PST
Brendan, do you for some reason think that the nspr base64 code wouldn't do the
right thing here? Is there some reason for using the nss ones over the nspr
ones? If so, I'd need to link against the nss code unless those methods are
exposed through some XPCOM interfaces, which is something I'd rather not do
unless there's no better way out.
Comment 13 Johnny Stenback (:jst, 2002-02-02 14:37:24 PST
bz, yes, that would make a lot of sense, but I won't start changing nspr API's
just becuase of this...
Comment 14 Brendan Eich [:brendan] 2002-02-02 15:35:00 PST
jst, I have no opinion about the NSPR vs. NSS implementations of btoa and atob
-- in fact I wonder why we have two in closely related modules.  I was struck by
the fact that classic used precursors of the NSS routines.  Cc'ing wtc.

Comment 15 Wan-Teh Chang 2002-02-02 20:01:13 PST
I am not familiar with the nspr base64 code and the nss
atob and btoa code.  Sorry.
Comment 16 Robert Relyea 2002-02-04 15:24:20 PST
I think the NSS base 64 code is streaming while the NSPR base 64 code is one
shot. Ideally NSPR's version should support streaming and the NSS version should

This has been a long standing issue. At one point in the Navigator 3.0
developement there was as many as 5 different impementations of base64.

Anyway this case I suggest using the NSPR versions if at all possible.

BTW, as for linking against NSS directly, while I don't recommend it (you can
confuse PSM if you tweak the wrong NSS function), when we land nss 3.4, it would
be possible because nss is now compiled in separate dll's. Again, for almost any
other function this would not work (you would interfere PSM's usages), and you
would require BUILD_PSM2 to be always set to build mozilla if you tried this.

Comment 17 Johnny Stenback (:jst, 2002-02-04 18:11:41 PST
Created attachment 67837 [details] [diff] [review]
Same as above, but w/o the leaks.
Comment 18 Johnny Stenback (:jst, 2002-02-04 18:53:15 PST
Created attachment 67847 [details] [diff] [review]
Er, that wasn't right, but this should be...
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2002-02-04 21:17:47 PST
Comment on attachment 67847 [details] [diff] [review]
Er, that wasn't right, but this should be...

Comment 20 Johnny Stenback (:jst, 2002-02-05 18:01:24 PST
Created attachment 68062 [details] [diff] [review]
More understandable patch, same as above, just renaming things a bit...

This one's ready to go...
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2002-02-05 18:11:31 PST
Comment on attachment 68062 [details] [diff] [review]
More understandable patch, same as above, just renaming things a bit...

Comment 22 Johnny Stenback (:jst, 2002-02-05 18:12:18 PST
Comment on attachment 68062 [details] [diff] [review]
More understandable patch, same as above, just renaming things a bit...

Comment 23 Johnny Stenback (:jst, 2002-02-05 20:43:06 PST

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