You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2013/09/12 00:44:18 UTC

window.btoa

I have 2 failing tests left on wp7 due to a lack of support for window.btoa
The current FileTransfer.js implementation of getBasicAuthHeader relies on
window.btoa otherwise it does nothing.

There is no reason the conversion could not be done in native code,
presumably faster and easier, so I am wondering why someone chose to just
return null if the window did not have the method.
I also cannot easily override/clobber this method, since it is essentially
private.

(note all tests pass on wp8, which uses ie10.  wp7 is eternally ie9)

I have several options for fixing this, each with their own
strengths/weaknesses

a. polyfill window.btoa ( and atob ) using [1]
b. fix the js implementation so it will pass username:password on to
native, if it cannot pass base64 encoded data. ( this means changing the
common FileTransfer.js )
c. provide a different implementation in js for windows phone ( using a
windows phone only version of FileTransfer.js and clobbering )
d. some sort of mixture of the above, like polyfill via plugin.xml so we
can only include the polyfill in wp7

Thinking through this while writing it, I am thinking d. makes the most
sense, although it should probably be done by the File plugin, which needs
it also, and is a dependency of FileTransfer anyway.

Any other thoughts, platform specific considerations here?



[1] https://github.com/davidchambers/Base64.js/blob/master/LICENSE

@purplecabbage
risingj.com

Re: window.btoa

Posted by Andrew Grieve <ag...@chromium.org>.
No array buffers? That makes me :(.

I think any of your options would be fine. Even if you want to change the
common code to pass the auth as a separate parameter, I think we could
manage updating all of the platforms.


On Wed, Sep 11, 2013 at 7:27 PM, Jesse <pu...@gmail.com> wrote:

> What platforms use this?
> Seems to require Uint8Array and afaik any browser that supports Uint8Array
> is going to support atob and btoa natively already. Am I wrong?
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Sep 11, 2013 at 4:12 PM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > cordova.js has an implementation of btoa in lib/common/base64.js, there
> for
> > passing binary data over the bridge to native. It wouldn't be much of a
> > stretch to include atob() if there's a reason for it.
> >
> > We could update FIleTransfer.js to use the cordova-supplied version. That
> > would make sense if we want to support platforms that don't provide it.
> >
> > Ian
> >
> >
> > On Wed, Sep 11, 2013 at 6:44 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > I have 2 failing tests left on wp7 due to a lack of support for
> > window.btoa
> > > The current FileTransfer.js implementation of getBasicAuthHeader relies
> > on
> > > window.btoa otherwise it does nothing.
> > >
> > > There is no reason the conversion could not be done in native code,
> > > presumably faster and easier, so I am wondering why someone chose to
> just
> > > return null if the window did not have the method.
> > > I also cannot easily override/clobber this method, since it is
> > essentially
> > > private.
> > >
> > > (note all tests pass on wp8, which uses ie10.  wp7 is eternally ie9)
> > >
> > > I have several options for fixing this, each with their own
> > > strengths/weaknesses
> > >
> > > a. polyfill window.btoa ( and atob ) using [1]
> > > b. fix the js implementation so it will pass username:password on to
> > > native, if it cannot pass base64 encoded data. ( this means changing
> the
> > > common FileTransfer.js )
> > > c. provide a different implementation in js for windows phone ( using a
> > > windows phone only version of FileTransfer.js and clobbering )
> > > d. some sort of mixture of the above, like polyfill via plugin.xml so
> we
> > > can only include the polyfill in wp7
> > >
> > > Thinking through this while writing it, I am thinking d. makes the most
> > > sense, although it should probably be done by the File plugin, which
> > needs
> > > it also, and is a dependency of FileTransfer anyway.
> > >
> > > Any other thoughts, platform specific considerations here?
> > >
> > >
> > >
> > > [1] https://github.com/davidchambers/Base64.js/blob/master/LICENSE
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> >
>

Re: window.btoa

Posted by Jesse <pu...@gmail.com>.
What platforms use this?
Seems to require Uint8Array and afaik any browser that supports Uint8Array
is going to support atob and btoa natively already. Am I wrong?

@purplecabbage
risingj.com


On Wed, Sep 11, 2013 at 4:12 PM, Ian Clelland <ic...@chromium.org>wrote:

> cordova.js has an implementation of btoa in lib/common/base64.js, there for
> passing binary data over the bridge to native. It wouldn't be much of a
> stretch to include atob() if there's a reason for it.
>
> We could update FIleTransfer.js to use the cordova-supplied version. That
> would make sense if we want to support platforms that don't provide it.
>
> Ian
>
>
> On Wed, Sep 11, 2013 at 6:44 PM, Jesse <pu...@gmail.com> wrote:
>
> > I have 2 failing tests left on wp7 due to a lack of support for
> window.btoa
> > The current FileTransfer.js implementation of getBasicAuthHeader relies
> on
> > window.btoa otherwise it does nothing.
> >
> > There is no reason the conversion could not be done in native code,
> > presumably faster and easier, so I am wondering why someone chose to just
> > return null if the window did not have the method.
> > I also cannot easily override/clobber this method, since it is
> essentially
> > private.
> >
> > (note all tests pass on wp8, which uses ie10.  wp7 is eternally ie9)
> >
> > I have several options for fixing this, each with their own
> > strengths/weaknesses
> >
> > a. polyfill window.btoa ( and atob ) using [1]
> > b. fix the js implementation so it will pass username:password on to
> > native, if it cannot pass base64 encoded data. ( this means changing the
> > common FileTransfer.js )
> > c. provide a different implementation in js for windows phone ( using a
> > windows phone only version of FileTransfer.js and clobbering )
> > d. some sort of mixture of the above, like polyfill via plugin.xml so we
> > can only include the polyfill in wp7
> >
> > Thinking through this while writing it, I am thinking d. makes the most
> > sense, although it should probably be done by the File plugin, which
> needs
> > it also, and is a dependency of FileTransfer anyway.
> >
> > Any other thoughts, platform specific considerations here?
> >
> >
> >
> > [1] https://github.com/davidchambers/Base64.js/blob/master/LICENSE
> >
> > @purplecabbage
> > risingj.com
> >
>

Re: window.btoa

Posted by Ian Clelland <ic...@chromium.org>.
cordova.js has an implementation of btoa in lib/common/base64.js, there for
passing binary data over the bridge to native. It wouldn't be much of a
stretch to include atob() if there's a reason for it.

We could update FIleTransfer.js to use the cordova-supplied version. That
would make sense if we want to support platforms that don't provide it.

Ian


On Wed, Sep 11, 2013 at 6:44 PM, Jesse <pu...@gmail.com> wrote:

> I have 2 failing tests left on wp7 due to a lack of support for window.btoa
> The current FileTransfer.js implementation of getBasicAuthHeader relies on
> window.btoa otherwise it does nothing.
>
> There is no reason the conversion could not be done in native code,
> presumably faster and easier, so I am wondering why someone chose to just
> return null if the window did not have the method.
> I also cannot easily override/clobber this method, since it is essentially
> private.
>
> (note all tests pass on wp8, which uses ie10.  wp7 is eternally ie9)
>
> I have several options for fixing this, each with their own
> strengths/weaknesses
>
> a. polyfill window.btoa ( and atob ) using [1]
> b. fix the js implementation so it will pass username:password on to
> native, if it cannot pass base64 encoded data. ( this means changing the
> common FileTransfer.js )
> c. provide a different implementation in js for windows phone ( using a
> windows phone only version of FileTransfer.js and clobbering )
> d. some sort of mixture of the above, like polyfill via plugin.xml so we
> can only include the polyfill in wp7
>
> Thinking through this while writing it, I am thinking d. makes the most
> sense, although it should probably be done by the File plugin, which needs
> it also, and is a dependency of FileTransfer anyway.
>
> Any other thoughts, platform specific considerations here?
>
>
>
> [1] https://github.com/davidchambers/Base64.js/blob/master/LICENSE
>
> @purplecabbage
> risingj.com
>