Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EE4B910A2F for ; Wed, 11 Sep 2013 22:44:44 +0000 (UTC) Received: (qmail 98838 invoked by uid 500); 11 Sep 2013 22:44:44 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 98811 invoked by uid 500); 11 Sep 2013 22:44:44 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 98803 invoked by uid 99); 11 Sep 2013 22:44:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Sep 2013 22:44:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of purplecabbage@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-ob0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Sep 2013 22:44:39 +0000 Received: by mail-ob0-f180.google.com with SMTP id va7so4115118obc.39 for ; Wed, 11 Sep 2013 15:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wVHI3yp8YBtFMusUuAJvdan4yi0ocbYwvRwMv9OXbr4=; b=dgWDohNjWLlr4uSZ3qZ2LQ+3Y5R2ZnswZKv5j9c1dY6sctAAyVD6jI+BR3tQXy1iBy Qd6kNdqGfzzyv8D1bG5nUqTyLzsuLG+L1LzQM6bhCONuAgQwDuu95Dhpptwdterag19l Rwln0F/Vyx/gxA8RUc/sNthoy4i26mo4rPw0laT1i+K5xif1kz27Zlmr+lNqsLoJk68E 0j9rfw7khvGkSQbzUNtjiavn/dt8VwWGJtvDorXDA8+Bjv7TlyhihMDy80wkKtg8AHLo 5XcQWo1YW9qRGM0I1J227Rfod0jMJOgeokY1p6zZV7kKJYq7HTuz1svVlJ6nr883ALG8 F5Sg== MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr3737826oer.8.1378939458194; Wed, 11 Sep 2013 15:44:18 -0700 (PDT) Received: by 10.76.99.177 with HTTP; Wed, 11 Sep 2013 15:44:18 -0700 (PDT) Date: Wed, 11 Sep 2013 15:44:18 -0700 Message-ID: Subject: window.btoa From: Jesse To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=089e0149d0ae92994404e6235c6a X-Virus-Checked: Checked by ClamAV on apache.org --089e0149d0ae92994404e6235c6a Content-Type: text/plain; charset=ISO-8859-1 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 --089e0149d0ae92994404e6235c6a--