Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-12394] Mobile Web: Ti.Blob does not do Base64 encoding/decoding as specified in the docs

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionDuplicate
Resolution Date2013-03-18T18:40:37.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsMobileWeb
Labelsn/a
ReporterYaroslav Pidstryhach
AssigneeIngo Muschenetz
Created2012-11-26T14:03:45.000+0000
Updated2014-06-19T12:42:39.000+0000

Description

The Titanium documentation [implies](http://docs.appcelerator.com/titanium/2.1/#!/api/Titanium.Utils-method-base64encode) that Mobile Web Blobs store their data in the Base64 form: {quote}On Mobile Web, if obj is a [Titanium.Blob] containing binary data, then obj is returned unmodified because the binary blob is already base64 encoded.{quote} However, the current implementation of Ti.Blob on Mobile Web does not seem to apply Base64 encoding/decoding. Also, Titanium.Network.HTTPClient returns unencoded blobs (with raw binary data). A short code example follows. Expected behavior: 'xhr.responseData' is Base64-encoded. Actual behavior: 'xhr.responseData' is not Base64-encoded.
    var xhr = Titanium.Network.createHTTPClient();
     
    xhr.onload = function()
    {
        var blob = xhr.responseData;  // should be Base64-encoded, but isn't
         
        // Loading image from blob to an image view will fail, because "blob" is not Base64-encoded
        // imageView1.image = blob;
    };
     
    downloadButton.addEventListener('click',function() {
        xhr.open('GET','/images/a-logo.png');
        xhr.file = Ti.Filesystem.applicationDataDirectory + 'a-logo.png';
        xhr.send();
    });

Attachments

FileDateSize
HttpClient.zip2013-01-23T14:39:18.000+00003693756

Comments

  1. Bryan Hughes 2013-01-17

    Can you attach a test case?
  2. Eduard Serdyuk 2013-01-18

    This example checks Blobs properties: responseData, file, nativePath Expected behavior:'responseData' will be Base64-encoded,'file' and 'nativePath' will not be undefined. Actual behavior: 'responseData' is not Base64-encoded, 'file' and 'nativePath' are undefined. <code><pre> var xhr = Titanium.Network.createHTTPClient(); xhr.onload = function() { var blob = xhr.responseData; Ti.API.info('Blob with Base64-encoded data:'+blob); //Load image from blob to ImageView1 imageView1.image = blob; //Check properties 'file' and 'nativePath' of Blob //Properties 'file' and 'nativePath' arent set in current HttpClient if (!!blob.file) { Ti.API.info('File name:'+blob.nativePath); //load data from file to ImageView2 imageView2.image = blob.file.read(); } else { Ti.API.info("Property 'file' is missing"); } }; downloadButton.addEventListener('click',function() { xhr.open('GET','/images/a-logo.png'); xhr.file = Ti.Filesystem.applicationDataDirectory + 'a-logo.png'; xhr.send(); });
  3. Bryan Hughes 2013-01-21

    Your test case is incomplete. imageView1 and imageView2 are never defined or created. Please attach a complete test case that I can run without modification
  4. Eduard Serdyuk 2013-01-21

    See attachments : ImageLoader1.zip
  5. Bryan Hughes 2013-01-22

    The attached test case does not work in iOS. HTTPClient cannot connect because there is no server to connect to. The test case must work in iOS (and Android) so I can compare with Mobile Web.
  6. Eduard Serdyuk 2013-01-23

    Attached is an improved demo for this bug. The pre-fix and post-fix behavior was verified on: - Mobile Web in MacOS (10.8.2, Safari); - Android 4.0.4 device; - Android 2.3 emulator; - iOS 6 simulator. Please refer to the comments in the app.js source code file for more info.
  7. Bryan Hughes 2013-01-23

    For reference, we always add a link to the PR in the JIRA ticket. Please make sure to do so in the future. PR: https://github.com/appcelerator/titanium_mobile/pull/3693
  8. Bryan Hughes 2013-01-23

    The attached test case forks for mobile web vs iphone. That makes the comparison invalid. You need to remove all forks so that the exact same code runs on both platforms.
  9. Yaroslav Pidstryhach 2013-01-23

    The fork is inevitable:

    Browsers will generally not open (via XMLHttpRequest) remote files from a domain that's different from the domain hosting the application. So we cannot use a public URL, and must supply a local image URL (unless you host the MW app on the public server as well).

    On the other hand, there's no way to use a local image URL on an Apple device (with an URL that would also work in Mobile Web).

    That's why we supply different URLs for different platforms. Note that the difference does not affect the functionality we're proposing to fix (Blob encoding and missing properties).
  10. Bryan Hughes 2013-01-23

    You can open remote files that have CORS enabled in MW
  11. Yaroslav Pidstryhach 2013-01-24

    Thanks. The sample is now updated as you requested. I cannot attach it, though, because I lack the permissions on the new location (TIMOB). I will contact you via email.
  12. Bryan Hughes 2013-01-24

    In your sample app you have the following line:
        Ti.API.info('Blob with Base64-encoded data:'+blob);
        
    In iOS this gives the following output:
        [INFO] Blob with Base64-encoded data:[object TiBlob]
        
    I'm not sure why the toString() method isn't doing something more interesting on iOS (bug perhaps?), but it nonetheless means we can't compare results. You'll need to find another way to demonstrate the parity issue.
  13. Yaroslav Pidstryhach 2013-01-28

    In the pull request you commented: "I dug into this issue a little more, and, in short, the wrong thing was fixed. HTTPClient works just fine, and Blob mostly works just fine (there are some issues with toString, but that is unrelated to this issue). The bug is in ImageView. We don't base64 encode blobs anymore, so imageview needs to be updated to base64 encode the data from blobs." Then it looks like documentation for base64encode should be updated, because it implies that blobs are always base64 encoded.
  14. Bryan Hughes 2013-01-28

    Yeah, that couldn't hurt, although to be honest it shouldn't matter that much because Blob is supposed to be a black box, and it doesn't matter to users how it's implemented.
  15. Daniel Sefton 2013-03-18

    Hi Bryan/Yaroslav, what are the next steps for this issue? Is this still a docs problem, or will a new pull request need to be made? Cheers.
  16. Bryan Hughes 2013-03-18

    Duplicate of TIMOB-12416

JSON Source