Closed
Bug 123003
Opened 23 years ago
Closed 23 years ago
window.atob and window.btoa are not implemented
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla0.9.9
People
(Reporter: georg, Assigned: jst)
Details
(Whiteboard: [HAVE FIX])
Attachments
(1 file, 3 obsolete files)
4.86 KB,
patch
|
bzbarsky
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Confirming in Build 2002013003, win98 ->OS All
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Assignee | ||
Comment 2•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Hardware: PC → All
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.9
Assignee | ||
Comment 3•23 years ago
|
||
Bz, Brendan, reviews?
Comment 4•23 years ago
|
||
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?
Attachment #67553 -
Flags: needs-work+
Comment 5•23 years ago
|
||
http://lxr.mozilla.org/classic/source/lib/libmocha/lm_win.c#2741 and below provide source for the Classic atob and btoa. /be
Assignee | ||
Comment 6•23 years ago
|
||
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.
Assignee | ||
Comment 7•23 years ago
|
||
Brendan, yes, but that code uses ATOB_AsciiToData() (n' friend), which according to lxr always return null (?), see http://lxr.mozilla.org/classic/ident?i=ATOB_AsciiToData
Reporter | ||
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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....
Reporter | ||
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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 http://lxr.mozilla.org/mozilla/source/security/nss/lib/util/nssb64d.c#813 -- I trust these preserve all the semantics. Cc'ing relyea. /be
Assignee | ||
Comment 12•23 years ago
|
||
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.
Assignee | ||
Comment 13•23 years ago
|
||
bz, yes, that would make a lot of sense, but I won't start changing nspr API's just becuase of this...
Comment 14•23 years ago
|
||
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. /be
Comment 15•23 years ago
|
||
I am not familiar with the nspr base64 code and the nss atob and btoa code. Sorry.
Comment 16•23 years ago
|
||
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 disappear. 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. bob
Assignee | ||
Comment 17•23 years ago
|
||
Assignee | ||
Comment 18•23 years ago
|
||
Attachment #67553 -
Attachment is obsolete: true
Attachment #67837 -
Attachment is obsolete: true
Comment 19•23 years ago
|
||
Comment on attachment 67847 [details] [diff] [review] Er, that wasn't right, but this should be... r=bzbarsky
Attachment #67847 -
Flags: review+
Assignee | ||
Comment 20•23 years ago
|
||
This one's ready to go...
Attachment #67847 -
Attachment is obsolete: true
Comment 21•23 years ago
|
||
Comment on attachment 68062 [details] [diff] [review] More understandable patch, same as above, just renaming things a bit... r=bzbarsky
Attachment #68062 -
Flags: review+
Assignee | ||
Comment 22•23 years ago
|
||
Comment on attachment 68062 [details] [diff] [review] More understandable patch, same as above, just renaming things a bit... sr=vidur
Attachment #68062 -
Flags: superreview+
Assignee | ||
Comment 23•23 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•