[TIMOB-12394] Mobile Web: Ti.Blob does not do Base64 encoding/decoding as specified in the docs
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Duplicate |
Resolution Date | 2013-03-18T18:40:37.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | MobileWeb |
Labels | n/a |
Reporter | Yaroslav Pidstryhach |
Assignee | Ingo Muschenetz |
Created | 2012-11-26T14:03:45.000+0000 |
Updated | 2014-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
File | Date | Size |
---|---|---|
HttpClient.zip | 2013-01-23T14:39:18.000+0000 | 3693756 |
Can you attach a test case?
This example checks Blob
s 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' aren
t 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(); });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
See attachments : ImageLoader1.zip
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.
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.
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
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.
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).You can open remote files that have CORS enabled in MW
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.
In your sample app you have the following line:
In iOS this gives the following output:
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.
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.
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.
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.
Duplicate of TIMOB-12416