Becky, do you know why this escaping was originally put in place? From our investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it, and the iOS-specific readAsText implementation.
If no one can remember why it was there (its existence predates the porting to Apache repos, so I can't see the commit that added it) and it seems to pass all the tests, then I vote to remove this extra complexity. Braden On Tue, Jan 8, 2013 at 10:21 AM, Braden Shepherdson <bra...@chromium.org>wrote: > Okay, Andrew and I investigated this a bit more this morning and found > that I was getting some broken results. > > I can't reproduce the broken tests due to escaping, I suspect I had an old > version that wasn't merging in the iOS version of FileReader. > > However, we continue to see that at least on 6.0 (downloading the 5.0 > simulator to check) on the default bridge, removing the encoding and > decoding works fine, including for international characters. I'll follow up > with the results on 5.0, and maybe experiment with other bridge modes too. > Possibly this is an old workaround for a bug in iOS versions we no longer > support. > > Braden > > > On Tue, Jan 8, 2013 at 9:05 AM, Braden Shepherdson <bra...@chromium.org>wrote: > >> Um, what Becky describes is exactly the opposite of what I saw. The test >> for international characters was failing before I removed the encoding >> because the percent-encoded string did not match the unencoded expectation. >> When I removed the encoding from the native code, then all the tests >> including that one started passing. >> >> I edited the common js implementation of readAsFile to handle the >> slicing, and that's working. I didn't think to check for platform-specific >> implementations. Now that I'm looking at that implementation, I'm wondering >> why it isn't being used, since then the decoding should be working and the >> slicing should be broken, but I've never seen that test result. >> >> Braden >> >> >> On Mon, Jan 7, 2013 at 8:39 PM, Andrew Grieve <agri...@chromium.org>wrote: >> >>> Right, what Becky said. >>> >>> It might be worth looking into having the iOS bridge take care of >>> international characters directly instead of special-casing the >>> FileReader. >>> We should be able to escape characters using \uXXXX instead of percent >>> escaping them. If you're interested in looking into this, let me know. >>> Otherwise I'll look into it. >>> >>> >>> On Mon, Jan 7, 2013 at 8:16 PM, Becky Gibson <gibson.be...@gmail.com> >>> wrote: >>> >>> > The reason for encoding on iOS was to support international characters. >>> > The response from read as text is decoded in the iOS specific version >>> of >>> > readAsText at >>> > >>> https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.jsline65. >>> I wouldn't suspect that the all of the mobilespec file tests >>> > would pass with the encoding removed since there are tests to check for >>> > extended characters? >>> > >>> > Becky >>> > >>> > Sent from my iPad >>> > >>> > On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <bra...@chromium.org> >>> > wrote: >>> > >>> > > I've recently been implementing support for Blob.slice() for >>> FileReader >>> > > files (sort of). With real native File and Blob objects, they >>> actually >>> > hold >>> > > the binary data. Cordova File objects are just records passed to >>> > > FileReaders. Regardless, the API for File.slice() is identical: it >>> takes >>> > a >>> > > start and optional end position, and returns a new File. Asking >>> > FileReader >>> > > to fetch that new file will return just the specified segment of the >>> > file. >>> > > >>> > > Some examples are in order. Suppose the file we're reading contains >>> the >>> > > text: >>> > > "All that is gold does not glitter, not all those who wander are >>> lost." >>> > > Then >>> > > f.slice(4, 8) would result in "that" >>> > > f.slice(9) would be "is gold does not glitter, not all those who >>> wander >>> > are >>> > > lost." >>> > > f.slice(-5, -1) would be "lost" >>> > > >>> > > This is implemented on Android and iOS for both reading text and >>> reading >>> > > data URLs. It's straightforward to implement on other platforms, and >>> I >>> > > encourage maintainers of other platforms to add this. >>> > > >>> > > I'll be updating the docs tomorrow, including the following quirk on >>> iOS. >>> > > >>> > > >>> > > That quirk is that iOS encodes the response to readAsText using >>> > %-escapes, >>> > > so that spaces become %20 and so on. This breaks a handful of spec >>> tests >>> > > including mine. It seems very puzzling, since a quick test with that >>> > > encoding removed shows that all the specs are now passing. I didn't >>> > commit >>> > > that, I just wanted to see if the bridge code would die horribly or >>> > > something. This has been in the codebase as far back as Github's >>> history >>> > > goes (the name change to Cordova), so I was unable to discover the >>> > original >>> > > reason for it. >>> > > >>> > > Shaz, Andrew, any idea what's going on here? Is this a relic of an >>> old >>> > > bridge that can be removed? I'm not sure whether this is a breaking >>> > change >>> > > for iOS, since Android and presumably other platforms do not do this. >>> > > >>> > > Braden >>> > >>> >> >> >
