I've been looking into this as it affects to my current project and it seems it doesn't have an easy fix as this is a webview problem, not just phonegap.

It seems to me that the new webview ignores the setWebChromeClient parameter, or at least the openFileChooser function.

I've opended a stackoverflow thread asking about the input file on android 4.4 webview and started a bounty: http://stackoverflow.com/questions/19882331/html-file-input-in-android-webview-android-4-4-kitkat
If I get some answers I'll fix it on cordova too.

Bad news, I opened an issue on the android open source project and the answer was:

Status: WorkingAsIntended
unfortunately, openFileChooser is not a public API. We are working on a public API in future releases of Android.

http://code.google.com/p/android/issues/detail?id=62220

If truly a feature-regression on Android 4.4 that's bad news. Would expect to hear more about this as more people upgrade to 4.4 and their Cordova (or other webview-based) apps start breaking.

Our Cordova app requires image uploading to be useful at all, so this is a show-stopper for us.

Would like to hear more confirmation from the Android and Cordova crews. Perhaps there's some kind of work around that can be hacked together involving Cordova file access... just don't know, haven't had to look into that before. I wouldn't be crazy about having to have a separate image-upload workflow for Cordova users and web users.

FYI, discussion in the dev mailing list: http://markmail.org/thread/zmwtu4fi56r4dnqq

We can't answer there, right?
I've looked into android 4.4 source code and the openFileChooser with the 4.1+ syntax (public void openFileChooser(ValueCallback<Uri> uploadMsg, String acceptType, String capture))
but it just doesn't work now, and by the google's answer, it seems that they have intentionally removed it

So, apparently <input type=file> is even causing trouble for Chrome on KitKat. There's no quick fix we can use, so will need to hack it up if we want to make it work. Likely it will be fixed in a future update.

Kitkat is only on Nexus devices, this is not a blocker.

Andrew Grieve, it doesn't look like they are paying attention to the android issues list above. Are you seeing this getting more attention somewhere else? I'd just like to follow the progress.

Android 4.4 Kitkat is expanding its roll-out to Nexus tablets in the next couple of days, so the impact of this issue is only going to widen. Perhaps that will get it more attention.

I've read that android 4.4 won't include a web browser, and vendors will have to create their own using a webview or license chrome, so if they don't license chrome they will have this bug on their browsers. If this happens, maybe they fix it.

I've looked at this a bit, to see if there is a workaround, especially a workaround that could be transparent to app developers. Here is what I've found thus far.

Prior to Android 4.4, Android's WebChromeClient class had an undocumented public openFileChooser() method that had a default implementation to ignore what was passed to it. CordovaChromeClient.java would override that method to grab a reference to the ValueCallback, start a file picker activity and get the result, and pass the value back by invoking ValueCallback.onReceiveValue(filePickerResult). I think that is basically the callback which allows us to take the result from the file picker and set the value of the form's input object. There has been chatter that this undocumented public method has disappeared in 4.4, but I think that is a red herring, it should still be there: see https://android.googlesource.com/platform/frameworks/base/+/android-4.4_r1/core/java/android/webkit/WebChromeClient.java - it is still there and unchanged from 4.3. But note that the javadoc for that method has always had a "@hide" tag, which keeps it out of the generated javadoc and appears to also remove that method from the android.jar in the SDK on the workstation (which is why Eclipse complains if @Override is used in CordovaChromeClient.java - android.jar on the workstation has only the non-hidden public methods). That's fine, because the android.jar from the workstation doesn't go into the apk, I'm assuming that the full class with public-hidden and private methods (in dex format) gets resolved at runtime on the device, which includes the openFileChooser() method in WebChromeClient. So I think it is safe to ignore the "openFileChooser() method was removed in 4.4" discussion, though it is hard to explicitly prove it other than looking at the Android source.

So then that means that our openFileChooser() probably isn't getting called. https://code.google.com/p/android/issues/detail?id=62220 fits right on that, and reading comment #24 there indicates there is a Chromium bug that was fixed in the Chromium source on Nov 19, which will be shippable in a later version of Chromium. So the hope is that fixes it, assuming there is a way to get that newer Chromium on the device ( see https://plus.google.com/+GoogleChromeDevelopers/posts/4QYG9AE589M )

So on to looking for any viable workarounds...

The type="file" input button does generate an onClick event. So anyone can write js to respond to that event. But the value property of the type="file" input object in the DOM is read-only in js, so it isn't possible to set it from js. That is for security reasons.

So if it is not possible to set the input value via js, and openFileChooser() in CordovaChromeClient no longer gets called so we never get a handle to the ValueCallback, I'm not seeing any way that we could set the value of the file input button, even if we were to provide our own picker activity. This means there is no way for a type="file" input to be used to store the result from a picker.

So then that leaves the us with having to use some other type of input object to store the filename. And the expected issue with that is the browser's form processing wouldn't know to send the file's contents instead of the filename. Perhaps we could take over the submit action and do an xhr2.send(FormData) using a transient form we constructed ourselves from the original HTML one, with the same action and method. But this sounds like a bad idea, similar to our earlier effort to recreate a camera app to keep our suspended activity from getting killed when RAM runs short.

So now it sounds like there is no viable way to workaround this in a way that is transparent to an app developer. The only workaround is for them to modify their app to use the FileTransfer plugin in the case of Android 4.4, assuming their server's service endpoint can deal with that input/upload.

Does anyone have other ideas on a viable workaround? Anything I've gotten wrong?

I changed my app to use FileTransfer for android and kept input file on iOS

It happens to me too on Cordova 3.2.0. Any idea on when is this going to be solved, and with which Cordova version will this be released?

Thanks,

This is not a bug in Cordova. It is a bug in the Chromium webview, and Google needs to fix it. According to https://code.google.com/p/chromium/issues/detail?id=278640 it appears the bug might be fixed in Chromium 33, whereas Android 4.4 currently has Chromium 30. It is unclear when Android 4.4 will get updated to Chromium 33, and how it will get it (Android system update or an app/component self-update). See https://developers.google.com/chrome/mobile/docs/webview/overview#will_the_new_webview_auto-update . To suggest that this would happen in the next 3 months is a wild uninformed guess. (No winking implied, seriously.)

I don't think this issue is specific to any Cordova versions. It is specific to Android 4.4, and probably occurs on all Cordova versions that run there.

No, the chromium bug is a different one, the chromium bug is related to the new android 4.4 storage framework ( same problem as this phonegap bug I've opened https://issues.apache.org/jira/browse/CB-5398, and affects chrome too, and any other app that try to get an url from the result of an Intent.ACTION_GET_CONTENT ).

the problem here is the file picker isn't even called because overwriting openFileChooser private function isn't working on android 4.4
the file picker is opened on chrome and chromium, but not on the webview.

But you are right, it isn't really a cordova bug, it's a android 4.4 webview bug. The problem is cordova is based on the webview, so the bug extends to cordova

Commit de8a4181cdf51ab40e4bc95e1d12f567a1c14ea8 in branch refs/heads/master from Mike Billau
[ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=de8a418 ]

CB-5294: Add input type=file Android quirk

I've added a note to the Platform Upgrade Guide about this bug (it's kinda weird, we don't list Android platform-wide quirks anywhere so the Upgrade Guide seemed like a decent enough place to stick it.)

Lets keep this ticket open so that every Android update we can check to see if this has been resolved, and if so, remove the quirk.