Supported features flags, handling browsers w/ no support for Fine Uploader

[andrew-kzoo]

I use FineUploader across multiple browsers as an optional file upload component in a larger form system. Some browsers (iOS < 6.0) don't support file uploads.

Would it be possible to add a unsupportedBrowserMessage option and behavior when FU is used in a browser which doesn't support <input type="file">, e.g replace <div> with unsupported browser message on init?

The following offers a simple method for feature detection of file uploads:

Detect browser file input support

function hasFileUploadSupport(){
  var hasSupport = true;
  try{
    var testFileInput = document.createElement('input');
    testFileInput.type = 'file';
    testFileInput.style.display = 'none';
    document.getElementsByTagName('body')[0].appendChild(testFileInput);
    if(testFileInput.disabled){
      hasSupport = false;
    }
  } catch(ex){
     hasSupport = false;
  } finally {
    if(testFileInput){
      testFileInput.parentNode.removeChild(testFileInput);
    }
  }
  return hasSupport;
}

alert(hasFileUploadSupport());

[rnicholus]

I think this is a good idea. I'll also likely provide an API function for FineUploaderBasic mode users. I'll schedule this for 3.4. I already have a lot of items scheduled for 3.4, so it may be pushed into a later release if things get too crazy.

[laeubi]

It would be nice to have a gneral purpose object (maybe in qqUtil?) that represent what features are avaiable, (e.g. resume downloads, drag'n'drop etc...) so it is possible to present users a list of options the can use right now, and options they might can use with a more recent browser...

[rnicholus]

@laeubi This is not really possible for all features. However, there are some such utility functions that cover feature support. I'll be sure to keep this in mind when working on this particular case in the next version as well.

[laeubi]

Yeah I see them, It just seems that they evaluate on each call so I just wondered if it would be possible to just calcualte it once and the present this via a general "feature" object, it would then ven be possible to assign messages to feature keys that could be presented to the user ... but thats just an idea that crossed my mind :-)

[rnicholus]

@laeubi That's a pretty good idea. I'll keep that in mind when I start work on this case. I may split off your idea into a separate case, but for now, I'll keep it here. Thanks again.

[rnicholus]

I'll start looking into this now for 3.5.

[rnicholus]

So, my plans here are:

1. add a unsupportedBrowserMessage option and default behavior when FU is used in a browser which doesn't support <input type="file">, e.g append an "unsupported browser" message to the top of the container element.
2. Create a qq.supportedFeatures object that contains flags for each feature. This object can either be populated/initialized completely when the library loads, or it can be loaded (and values cached) on demand. The former may be easiest. I don't think this will result in a noticeable increase in library init/startup time.

[rnicholus]

This is actually going to be quite tricky to implement. The test required to determine if file input elements are supported requires the existence of the body element. My intent is to initialize all feature flags during initialization of the uploader, but the uploader code may be loaded before the body tag is present. On approach is to simply initialize the feature flags after the window's "onload" event. However, this may be too late, especially if the code integrating Fine Uploader uses something like jQuery's document.ready() check, which may fire before the window's "onload" event. I'd rather not duplicate the logic in jQuery's ready function. It may just be easier and less risky (in terms of breaking Fine Uploader entirely for existing users) if I resort to the dreaded user agent string parsing to determine if IOS5 is the current user agent.

Thoughts?

Also, testing support for file input elements requires either access to an IOS5 device (I'm not sure I have access to such a device) or access to an IOS5 simulator. Apple has made it very difficult to run an IOS5 simulator with the latest xcode in Mountain Lion. The only IOS simulator with the latest versions of xcode on mountain lion is 6.x. I'm attempting to download xcode 4.4.1 in hopes of running the IOS 5.1 simulator bundled with that, and we'll see how that works.

[rnicholus]

I was able to run an IOS5 simulator by navigating to the simulator packaged in the xcode 4.4.1 disk image. After eliminating the code that depends on the body tag in my file input support detection code, the lack of file input support was still detected. I will need to confirm that adding the file input element to the DOM is not required to accurately detect lack of file input support on a real IOS5 device though.

[rnicholus]

I have completed all planned work on this feature. I still need to run some tests on a real IOS5 device before I merge this into 3.5-IP.

A new object containing flags that correspond to features, qq.supportedFeatures, is documented in the docs/feature-detection.md file. I've also linked to it in various places throughout the documentation.

I also append a <div> containing the contents of the new unsupportedBrowser property of the messages option if FineUploader mode is in use and uploads are not possible in the current user agent. Uploads are not possible if a file input element is not supported, or if the expected property of the cors option is set to true and the current user agent does not support XHR2 uploads and window.postMessage is not implemented by the user agent. If this type of message is required in FineUploaderBasic mode, or if the default (simple) styling of this message in FineUploader mode is not sufficient, the integrator can check the value of the qq.supportedFeatures.uploading flag before initializing Fine Uploader and react appropriately.

[rnicholus]

Tested and confirmed on a real IOS5 device.

This has been completed in 3.5-IP.