Upload fails on iOS 12 on iPhone 6/7/8

[RobAndersson]

This is an odd issue we observed in our project, that is very specific. It only occurs in the iPhone simulator for 6, 7 and 8, with iOS 12. Other phones on iOS 12 works fine, and 6/7/8 phones with iOS 11 and 13 works too. We have a ReactNative app with a WebView; and it also seemed that it worked with the "old" WebView, but not the newer WkWebView. At the moment I am not sure if the problem existed in Safari or not, but I think so. But, I don't think this matters too much for the question.

The failure is that after the user has selected a file for upload, nothing happens (no attempt at uploading the file in the background). Since it is on an iPhone in an embedded web app, it is fairly hard to debug.

Anyway, we sort-of identified the problem, and a potential fix, but the "offending" code is pretty complicated, so it is hard to see what's really going on, and what side-effects a fix could result in.

The culprit in this specific case is that _handleFileTreeEntry() returns/resolves a single (file) object, where the caller expects an array.

It begins (or ends here):
_onAdd(null, data); // data.files is supposed to be an array in this function

However, that data.files is set in add() from a Promise that bubbles down from this chain:
_getFileInputFiles -> _getSingleFileInputFiles -> _handleFileTreeEntries -> _handleFileTreeEntry

In _handleFileTreeEntry(), we have this code:

       if (entry.isFile) {
          if (entry._file) {
            // Workaround for Chrome bug #149735
            entry._file.relativePath = path;
            dfd.resolve(entry._file);  // <-- this may also be a problem
          } else {
            entry.file(function(file) {
              file.relativePath = path;
              dfd.resolve(file);  // <--- THIS IS OUR PROBLEM
            }, errorHandler);
          }
        } else if (entry.isDirectory) {

Here, on the marked lines, it resolves to a single file, while in other parts of the function it resolves to a list of files. When we change the marked line to dfd.resolve( [ file ] ) it works in our test case.

So, does anyone know why this inconsistency exists, and what would break if one fixes it?

[blueimp]

_handleFileTreeEntry can return both a single file (e.g. if a single file was dropped), or multiple files (e.g. if a directory of files, or subdirectories with files) was dropped.

If you change the behavior here as in your example, it won't necessarily break things, but it wouldn't accurately represent the dropped folder hierarchy anymore.

Given that _handleFileTreeEntry is always wrapped by _handleFileTreeEntries, I'm surprised by the effect of your change.

_handleFileTreeEntries should always return a list of files (or an empty list).
Since it's a rather short and simple function, I think the problem is likely higher up the call stack.

Would be great if you could debug a little deeper here and report back.

[RobAndersson]

Thank you for looking into it. I need to appologize that I cannot do proper debugging at the moment, since I need my coworker's Mac (+xcode/emulator setup) in order to test, and I have to go by the notes we took during our last debug session. I'll try to do some more tests later this week.

But, there is still something funny going on I think.

_handleFileTreeEntries should always return a list of files (or an empty list).

I don't think it does, in this case. It will return an array of all the entries (Array.prototype.concat.apply([], arguments); where the arguments are what _handleFileTreeEntry() resolves to for each entry. I'm not sure, but it looks to me like that could be an array of arrays.

I agree that the fix is probably better higher up the stack. Ie something like this would probably be an equivalent fix:

      add: function(data) {
        ...
          this._getFileInputFiles(data.fileInput).always(function(files) {
            data.files = Array.isArray(files) ? files : [files];
            ...

But, my point is that, to me, _handleFileTreeEntries appears to be inconsisten whether or not a single file or an array of files is returned:

          ...
          dfd = $.Deferred(),
          ...
          errorHandler = function(e) {
            ...
            dfd.resolve([e]);    // <-- LIST of something
          },
          successHandler = function(entries) {
            ...
                dfd.resolve(files);    // <-- LIST of files most likely
              })
              .fail(errorHandler);
          },
          ...
        if (entry.isFile) {
          if (entry._file) {
            ...
            dfd.resolve(entry._file);     // <-- SINGLE file
          } else {
            ...
              dfd.resolve(file);     // <-- SINGLE file
            ...
        } else if (entry.isDirectory) {
          ...
        } else {
          ...
          dfd.resolve([]);     // <-- empty LIST 
        }
        return dfd.promise();

[blueimp]

That code snippet is from _handleFileTreeEntry, not from _handleFileTreeEntries. The latter function's code in its entirety is the following:

    _handleFileTreeEntries: function(entries, path) {
      var that = this;
      return $.when
        .apply(
          $,
          $.map(entries, function(entry) {
            return that._handleFileTreeEntry(entry, path);
          })
        )
        .then(function() {
          return Array.prototype.concat.apply([], arguments);
        });
    },

This code concatenates both single files and arrays of files into a single array as returned by _handleFileTreeEntry, as this is the behavior of Array.prototype.concat().

Can you reproduce the issue when using the demo on https://blueimp.github.io/jQuery-File-Upload/ on your iOS 12 iPhone 6/7/8 devices?

[RobAndersson]

Sorry for taking a while to reply. But we eventually figured out what was going on.

The cause was that in this application we were using jQuery 1.7.1, and when switching to 1.8 it worked again. So this is/was the same issue as #3538

But out of interest, what seemed to be the difference was jQuery's handling of promises and the resolved results. In the old jQuery version, the call stack between the resolve() in _handleFileTreeEntry() and eg. the add() method was ~5 and the result was unmodified (eg result/files as a FileObject and not an array). While in the newer version, the call stack was ~30 steps and somewhere in it, the FileObject got converted into an array.

Also, the reason this only affected Safari/WebView is that other browsers and versions avoid this execution path, by testing for fileInput.prop('webkitEntries') in _getSingleFileInputFiles. So, I think other browsers would also require jQuery 1.8+ if it wasn't for that condition.

In our case, this is an old and pretty big application with heavy use of jQuery and old plugins, so I didn't dare to upgrade jQuery. My solution insted was a small hack in jquery.fileupload.

// in _onChange:
             this._getFileInputFiles(data.fileInput).always(function (files) {
-                data.files = files;
+                data.files = $.isArray(files) ? files : [files]; // HACK: was just files
                 if (that.options.replaceFileInput) {
                     that._replaceFileInput(data);
                 }
             }

// in add:
             if (data.fileInput && !data.files) {
                 this._getFileInputFiles(data.fileInput).always(function (files) {
-                    data.files = files;
+                    data.files = $.isArray(files) ? files : [files]; // HACK: was just files
                     that._onAdd(null, data);
                 });
             } else {

// in send:
                                 dfd.reject();
                                 return;
                             }
-                            data.files = files;
+                            data.files = $.isArray(files) ? files : [files]; // HACK: was just files
                             jqXHR = that._onSend(null, data);
                             jqXHR.then(
                                 function (result, textStatus, jqXHR) {

So, in the end, this is somewhat resolved. I'm still a bit unsure if the code in _handleFileTreeEntries isn't relying on some obscure behaviour though, which works by accident. I don't really see why one should expect the single FileObject to be converted to an array in the resolve()-chain.

[blueimp]

Thanks for the response, @RobAndersson.
I'll leave this open for others to find.
I'm also still open for a potential workaround in the code itself, but would prefer to merge something that has a clear reasoning - at the moment we couldn't really pinpoint any code that is responsible inside this project.
Anyway thanks for coming back, this is already very appreciated!

[RobAndersson]

Maybe shouldn't be beating a dead horse, but...

I think a possible workaround, that has some reasoning to it, is what I pointed out in the original post.

That is, that _handleFileTreeEntry() resolves to an array of files rather than a single FileObject. Because what I think is happening is that somewhere the result is passed through a jQuery array function (not sure which), that has changed behaviour:

Old behviour:
function([Object]) => [Object]
function([Array]) => [Array]

New behaviour:
function([Object]) => [Array] (of a single [Object])
function([Array]) => [Array]

And that the code relies on the new behviour to convert it to an array, and get the consistent result from the _handleFileTreeEntry() function. In some cases that function resolves an array (eg. in successHandler) and sometimes a single object.

Just a note about the jQuery version, and why a fix might be worthwhile even though it is for an ancient version. If you use Google's JSAPI to load jquery with google.load("jquery", "1"); you are going to get v1.7.x, and many people (including me) tend to use that because we reuse old code without thinking about it... :)

[blueimp]

Thanks for providing more info.
I'm definitely still open to include a fix, I just prefer to clearly identify the issue first.

I've looked at the source for jQuery 1.7 vs jQuery 1.12.4 and the $.map function uses a different way to handle Array-like objects between those versions.
Since you also reported that this might be related to webkitEntries, my current hunch is that in iOS 12, this property might return an Array-like object that is not correctly identified by the $.map function of jQuery 1.7 (and lower).

If you have the time, could you try out the following and report back if it fixes the issue?
In jquery.fileupload.js, find

fileInput.prop('webkitEntries')

and replace it with

$.makeArray(fileInput.prop('webkitEntries'))

Thanks in advance!

[blueimp]

Turns out this was a regression introduced in #3435, which replaced promise.pipe() with promise.then().

When reviewing this I didn't test with jQuery versions lower than 1.8 anymore and unfortunately the behavior of promise.then() only matched that of promise.pipe() from jQuery 1.8 and higher.

But it should finally be fixed now for old (< 1.8) jQuery versions with the latest release:
blueimp-file-upload@10.27.0