Obsolete
Status Update
Comments
wu...@gmail.com <wu...@gmail.com> #2
unfortunately, openFileChooser is not a public API. We are working on a public API in future releases of Android.
pr...@gmail.com <pr...@gmail.com> #3
ok :(
br...@gmail.com <br...@gmail.com> #4
So just to be clear, this feature (the file input element opening the file picker) was intentionally removed from webviews in Android 4.4?
I need to be clear on this because this is going to be a pretty significant problem for any Cordova/Phonegap developer (who might not, at the moment, have experienced this problem because 4.4 is still so new).
Is it going to be removed for Android 4.3 and below?
I need to be clear on this because this is going to be a pretty significant problem for any Cordova/Phonegap developer (who might not, at the moment, have experienced this problem because 4.4 is still so new).
Is it going to be removed for Android 4.3 and below?
sy...@gmail.com <sy...@gmail.com> #5
When will this be added back into Android, and what can we do in the mean time?
Before, people were overridding hidden methods - is there just some new hidden method that we have to override to get it working again?
Before, people were overridding hidden methods - is there just some new hidden method that we have to override to get it working again?
je...@gmail.com <je...@gmail.com> #6
We are working on a mechanism to support this, maybe as a public API. Unfortunately there is no workaround I know of at the moment. However, if developers have any preference for one of the options below, please let us know:
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
an...@logaan.com <an...@logaan.com> #7
I think I would preffer option 1.
BTW, I have read that android 4.4 won't include a browser and the device vendors will have to create their own browser usin a webview (or license chrome), that means any browser appart from chrome will have <input type="file"> working.
I've find out that <input type="file"> have a bug on chrome, if you choose documents and then one of the new android 4.4 options ("Recent", "Drive", "Images","Audio", "Downloads", "Internal storage"), it won't be able to pick the file, and the Drive option even make chrome crash
BTW, I have read that android 4.4 won't include a browser and the device vendors will have to create their own browser usin a webview (or license chrome), that means any browser appart from chrome will have <input type="file"> working.
I've find out that <input type="file"> have a bug on chrome, if you choose documents and then one of the new android 4.4 options ("Recent", "Drive", "Images","Audio", "Downloads", "Internal storage"), it won't be able to pick the file, and the Drive option even make chrome crash
pe...@gmail.com <pe...@gmail.com> #8
Great! This new "feature" in 4.4 that is "WorkingAsIntended" will cost us and many other companies a lot of money when we have to give support to all our customers and explain to them that it is no longer possible to upload files in our Android app in which we use WebChromeClient.
Thanks a lot!
Thanks a lot!
ki...@gmail.com <ki...@gmail.com> #9
[Comment deleted]
mi...@gmail.com <mi...@gmail.com> #10
This seems like when Apple decided people using the iPhone didn't really need to upload files through the browser. :p
We've just launched an app 9 days ago, which is now basically useless, and are left to explain to the customer that it's google's fault. :p
We've just launched an app 9 days ago, which is now basically useless, and are left to explain to the customer that it's google's fault. :p
mi...@gmail.com <mi...@gmail.com> #11
We work with numerous companies with dozens of different apps that make use of this feature. I can't for the life of me understand why such a feature would be removed. It lessens the features available within apps targeting the Android OS which makes phones powered by the Android OS less desirable.
I certainly hope something is worked out to address this as this is a huge loss in functionality. I'd be happy with either option #1 or #2 listed earlier.
I certainly hope something is worked out to address this as this is a huge loss in functionality. I'd be happy with either option #1 or #2 listed earlier.
do...@gmail.com <do...@gmail.com> #12
I'm suffering, crying for the same issue after spending hours thinking it was my fault. If there is *no* another option (documented or not), why did you remove it? What's the hell is that answer "working as intended"? Gosh.
Just one more thing, :facepalm:
Just one more thing, :facepalm:
do...@gmail.com <do...@gmail.com> #13
I would also prefer option #1
#12 it is your fault, it's not a public API what is hard to understand about it? Software development 101
#12 it is your fault, it's not a public API what is hard to understand about it? Software development 101
mi...@gmail.com <mi...@gmail.com> #14
[Comment deleted]
cd...@gmail.com <cd...@gmail.com> #15
#12 It is not your fault. openFileChooser may not be in the public API but this function is used in thousands of Android apps and now all these apps is broken. openFileChooser is the ONLY way to open up a file dialog when using the WebChromeClient.
It is a pity that the webview developers couldn't understand this them self.
It is a pity that the webview developers couldn't understand this them self.
ma...@gmail.com <ma...@gmail.com> #16
#13, What is hard to understand is that in this day and age, with all the boom in HTML5 hybrid apps, with Titanium and Phonegap on the market, you remove a basic functionality like uploading a file. It's 2013 guys, this is the sort of thing we should be able to take for granted that it works.
ol...@gmail.com <ol...@gmail.com> #17
I would use option one. It seems to be the cleanest way to handle file-chooser.
ta...@gmail.com <ta...@gmail.com> #18
#13 Just explain how to do a basic freaking standard file upload with the API and I'll happily use it. But there is *no* other way, no alternative... Or, are you suggesting that uploading an image from a mobile is not important and basic feature?
FFS, it's not only an annoyance to programmers, it's almost a betrayal. It s
OTH, even Chrome fails to upload images
http://youtu.be/MzIejKC-7fA
FFS, it's not only an annoyance to programmers, it's almost a betrayal. It s
OTH, even Chrome fails to upload images
ki...@gmail.com <ki...@gmail.com> #19
If you use phonegap isn't very difficult to create a plugin to pick a file
and then upload it with the file transfer and call it with a regular
button.
The native code is almost the same that the existing code on the
openFileChooser, call an intent that will return the file path.
and then upload it with the file transfer and call it with a regular
button.
The native code is almost the same that the existing code on the
openFileChooser, call an intent that will return the file path.
fd...@gmail.com <fd...@gmail.com> #20
You broke file-uploading and released 4.4 without a ready replacement or workaround? O_o
So even if app devs manage to hack around it, they'll have to maintain the hack forever to support phones stuck on 4.4 even after 4.5+ introduces a proper replacement function?
I need a Kitkat bar.
So even if app devs manage to hack around it, they'll have to maintain the hack forever to support phones stuck on 4.4 even after 4.5+ introduces a proper replacement function?
I need a Kitkat bar.
mi...@gmail.com <mi...@gmail.com> #21
Woah,surely Google is working on this issue?? We have a web app in the works that relys heavily on uploading photos via Chrome... Used to work fine until 4.4.
di...@gmail.com <di...@gmail.com> #22
Even when uploading a file using Gmail's mobile web version on Chrome it fails on 4.4. So Android 4.4 breaks Gmail on Chrome! I don't really care about the API details, but a modern browser MUST support file upload. Dear Android devs and managers, please take your user's feedback seriously and fix this major bug. Thanks.
ol...@gmail.com <ol...@gmail.com> #23
ck...@gmail.com <ck...@gmail.com> #24
FYI, the relevant Chrome bug seems to be http://crbug.com/278640
Looks like it's been fixed for Chrome 33 (9+ weeks away). Not sure if they used what #23 suggested.
Looks like it's been fixed for Chrome 33 (9+ weeks away). Not sure if they used what #23 suggested.
xg...@gmail.com <xg...@gmail.com> #25
#24, comments #29 and #30 from http://crbug.com/278640 are very insightful. At least they seem decided to fix it for webview aswell.
kl...@gmail.com <kl...@gmail.com> #26
Need this fixed too - solution #19 isn't a clean one, from what I understand is being proposed. It would seem the file upload takes place independently of the POST, so:
1. no session information is passed
2. need a mechanism to tie the uploaded file to the ultimate POST with the corresponding data
3. how long do we store the upload file while waiting for the POST that may not come
4. There is even more trouble when using a load-balancer and multiple web servers.
1. no session information is passed
2. need a mechanism to tie the uploaded file to the ultimate POST with the corresponding data
3. how long do we store the upload file while waiting for the POST that may not come
4. There is even more trouble when using a load-balancer and multiple web servers.
4a...@gmail.com <4a...@gmail.com> #27
#26, phonegap's file transfer uses a HTTP multi-part POST request, so you can pass the other form parameters at the same time you upload the file. (you will need a function to pick and add them to the file transfer options)
Here a simple example manually adding form params:
var options = new FileUploadOptions();
var params = {};
params.value1 = "test";
params.value2 = "param";
options.params = params;
var ft = new FileTransfer();
ft.upload(fileURI, encodeURI("http://some.server.com/upload.php "), win, fail, options);
Here a simple example manually adding form params:
var options = new FileUploadOptions();
var params = {};
params.value1 = "test";
params.value2 = "param";
options.params = params;
var ft = new FileTransfer();
ft.upload(fileURI, encodeURI("
mk...@gmail.com <mk...@gmail.com> #28
I vote for #2, as it is the simplest method. The web page being viewed should simply "work" without any additional wrapper code. I don't have to intercept events in order to click a hyperlink or a submit button, do I? (I know these events do not interact with the underlying OS the way the file upload does, but the general point stands.)
el...@gmail.com <el...@gmail.com> #29
[Comment deleted]
fo...@gmail.com <fo...@gmail.com> #30
[Comment deleted]
ni...@gmail.com <ni...@gmail.com> #31
#27 thanks for the sample. Unfortunately, I'm providing a "raw" app (plain java). Any suggestions/pointers where to look to create the same functionality?
Tnx.
Tnx.
ma...@gmail.com <ma...@gmail.com> #32
My vote for Option 1 .
Please don't just remove undocumented APIs that are widely used . Even though its not recommended to use Undocumented APIs , most of the apps use hell lot of these APIs to add functionality.
Please don't just remove undocumented APIs that are widely used . Even though its not recommended to use Undocumented APIs , most of the apps use hell lot of these APIs to add functionality.
sl...@gmail.com <sl...@gmail.com> #33
#6 I vote for a combination of both.
I prefer that by default the webview will automatically pop up a UI to choose a file. However we should be able to override the handler method so that would can provide our own functionality or extend the existing functionality.
example:
public void openFileChooser(ValueCallback<Uri> uploadMsg, String acceptType, String capture) {
// here I'm just going to use the default functionality and log it for testing
super.openFileChooser(uploadMsg, acceptType, capture);
Log.e("openFileChooser", "4.1+ - " + acceptType + " - " + capture);
}
I prefer that by default the webview will automatically pop up a UI to choose a file. However we should be able to override the handler method so that would can provide our own functionality or extend the existing functionality.
example:
public void openFileChooser(ValueCallback<Uri> uploadMsg, String acceptType, String capture) {
// here I'm just going to use the default functionality and log it for testing
super.openFileChooser(uploadMsg, acceptType, capture);
Log.e("openFileChooser", "4.1+ - " + acceptType + " - " + capture);
}
da...@gmail.com <da...@gmail.com> #34
Vote for OPtion 1. Prefer the old undocumented API be documented and supported.
al...@gmail.com <al...@gmail.com> #35
Please provide a workaround patch or something in the interim until you get his figured out. This is ridiculous.
me...@gmail.com <me...@gmail.com> #36
So many devices updated to 4.4 last night and now the app photo uploader is not working since users cannot select a file. What a HUGE mistake for Android and such a betrayal. "Working as Expected"
Why on earth would you do this to people?
Why on earth would you do this to people?
mi...@gmail.com <mi...@gmail.com> #37
[Comment deleted]
da...@gmail.com <da...@gmail.com> #38
U need to give us an option to upload files from web apps !!!!
du...@wilkins.info <du...@wilkins.info> #39
[Comment deleted]
ko...@gmail.com <ko...@gmail.com> #40
Agreed. We are in a holding pattern on this. What is the workaround or patch?
bu...@gmail.com <bu...@gmail.com> #41
Issue Status: WorkingAsIntended
This is ridiculous.
This is ridiculous.
ct...@gmail.com <ct...@gmail.com> #42
Working as Intended... Siriously? what a shame.
ma...@gmail.com <ma...@gmail.com> #43
Hey all, Let me start off by saying that the following comment relates to Phonegap/Cordova development.
I've been experiencing this issue as well so I wrote a Cordova FileChooser plugin to a "band-aid" for the time being. Basically, in Android 4.4(KitKat), as mentioned in previous comments, the file dialog is not opened. However the onclick event is still fired on <input type=file> so you can call the FileChooser plugin to open a file dialog and upon selection, you can set a variable that contains the full path to the file. At this point, you can use the FileTransfer plugin to upload to your server and hook into the onprogress event to show progress. This plugin is mainly configured for Android 4.4 so I would recommend to continue to use the native file dialogs for earlier versions of Android. There might be issues with the plugin as I have not fully tested all possible scenarios on many devices, but I have installed it on a Nexus 5 and it worked fine. I hope this helps out some of you.
https://github.com/cdibened/filechooser
I've been experiencing this issue as well so I wrote a Cordova FileChooser plugin to a "band-aid" for the time being. Basically, in Android 4.4(KitKat), as mentioned in previous comments, the file dialog is not opened. However the onclick event is still fired on <input type=file> so you can call the FileChooser plugin to open a file dialog and upon selection, you can set a variable that contains the full path to the file. At this point, you can use the FileTransfer plugin to upload to your server and hook into the onprogress event to show progress. This plugin is mainly configured for Android 4.4 so I would recommend to continue to use the native file dialogs for earlier versions of Android. There might be issues with the plugin as I have not fully tested all possible scenarios on many devices, but I have installed it on a Nexus 5 and it worked fine. I hope this helps out some of you.
le...@gmail.com <le...@gmail.com> #44
Please make it work as it was. My clients are calling me.
ma...@gmail.com <ma...@gmail.com> #45
waiting a solution....
mi...@gmail.com <mi...@gmail.com> #46
Please fix it. Thanks.
zo...@gmail.com <zo...@gmail.com> #47
@sgurun .. my vote goes to option 1:
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
This also goes for <input type="color" /> behavior, it floats the same boat..
1. having a WebViewClient style callback to let the app programmatically handle the file input selection
2. having a policy hardcoded into the webview e.g. that just popups the UI automatically when the file input button is pressed
This also goes for <input type="color" /> behavior, it floats the same boat..
4a...@gmail.com <4a...@gmail.com> #48
Maybe my solution can help some users:
Currently my solution is to generate an unique token on upload click and
redirect the user via the navigator to an upload page corresponding with
the token.
But it's not really smooth for the user.
Please Google, implement a real solution !
Currently my solution is to generate an unique token on upload click and
redirect the user via the navigator to an upload page corresponding with
the token.
But it's not really smooth for the user.
Please Google, implement a real solution !
ma...@gmail.com <ma...@gmail.com> #49
Vote for option 1
ra...@gmail.com <ra...@gmail.com> #50
How many people need to complain before they take this seriously?
If this was never part of the solution nobody would care but when your existing apps stop working then it's a BIG DEAL.
If this was never part of the solution nobody would care but when your existing apps stop working then it's a BIG DEAL.
mi...@gmail.com <mi...@gmail.com> #51
Please fix this issue. Waiting for solution.
Thanks in advance
Thanks in advance
mi...@gmail.com <mi...@gmail.com> #52
Ouch... really?
dd...@sypniewski.info <dd...@sypniewski.info> #53
Why would Google remove a feature before figuring out an alternative? Being able to upload files is kind of important for many apps.
dd...@sypniewski.info <dd...@sypniewski.info> #54
[Comment deleted]
[Deleted User] <[Deleted User]> #55
All this is fucking unbelievable.
File upload functionality should have been built into WebView from the very beginning in the first place: <input type="file"> is just a standard feature of HTML, supported in browsers when not only android but even smarthpones didn't exist yet, so a standard-compliant WebView that is supposed to show web content should support it out of the box without the need to write any extra code.
Then, the fact that you have to override a _hidden_ method (as opposed to a protected or public method) is even more shemeful.
But the fact that now you remove the feature and break existing apps that did it the only way they could (which, by the way, is the same as Android's own browser did it) is fucking unbelievable.
That said, I guess Android Browser does support file uploads on 4.4, right? (I don't have a 4.4 phone, so I can't try it). So, I guess the workaround is to look at its source code and do it the same way as they do. Until they break it again.
File upload functionality should have been built into WebView from the very beginning in the first place: <input type="file"> is just a standard feature of HTML, supported in browsers when not only android but even smarthpones didn't exist yet, so a standard-compliant WebView that is supposed to show web content should support it out of the box without the need to write any extra code.
Then, the fact that you have to override a _hidden_ method (as opposed to a protected or public method) is even more shemeful.
But the fact that now you remove the feature and break existing apps that did it the only way they could (which, by the way, is the same as Android's own browser did it) is fucking unbelievable.
That said, I guess Android Browser does support file uploads on 4.4, right? (I don't have a 4.4 phone, so I can't try it). So, I guess the workaround is to look at its source code and do it the same way as they do. Until they break it again.
ro...@gmail.com <ro...@gmail.com> #56
It doesn't work in the "Android" browser in 4.4. Tried in an emulator and on my phone with a custom ROM.
tu...@gmail.com <tu...@gmail.com> #57
I could be mistaken, but IOS natively supports input=file without any special coding. You click the upload button, and it gives you a choice of Camera, file list or something else, can't remember. But it is fluid and useful.
I agree with matteosi. For the basics, webview should support, but if developers want to extend it, that option should be done also.
I agree with matteosi. For the basics, webview should support, but if developers want to extend it, that option should be done also.
kl...@gmail.com <kl...@gmail.com> #58
Unbelievable
mi...@gmail.com <mi...@gmail.com> #59
Unbelievable
jm...@gmail.com <jm...@gmail.com> #60
I agree with matteosi.
I think that we should be provided as a basic function without special options from webview.
I think that we should be provided as a basic function without special options from webview.
mi...@gmail.com <mi...@gmail.com> #61
Is this for real?
Why on earth would Google remove BASIC functionality from the webview in 4.4 breaking already existing apps. Terrible decision, they could have at least provided us with an alternative.
Why on earth would Google remove BASIC functionality from the webview in 4.4 breaking already existing apps. Terrible decision, they could have at least provided us with an alternative.
mi...@gmail.com <mi...@gmail.com> #62
This is absolutely disgraceful!
I have apps in the play store right now that are using file upload in webviews. I can't believe such a large company like this still hasn't fixed an issue so major from NOV 2013!
Appalling.
I have apps in the play store right now that are using file upload in webviews. I can't believe such a large company like this still hasn't fixed an issue so major from NOV 2013!
Appalling.
si...@gmail.com <si...@gmail.com> #63
I see this thread is starting to gain more traction. One of the early advantages Android had over iOS is that this worked without having to download a third party component.
tu...@gmail.com <tu...@gmail.com> #64
On the top left of this page we see that this issue was closed: Nov 13. Shouldn't it be opened again? Google Android team please open this issue to show us that you are working on a solution.
ch...@gmail.com <ch...@gmail.com> #65
They said it's not a bug, it's working as intended, we shouldn't have used the private method openFileChooser oon the first place
mi...@gmail.com <mi...@gmail.com> #66
#65 Whilst I do agree that it is a private method and maybe we shouldn't have been using it, it is a basic feature and frequently needed so what else would we have used? The feature needs to be added in and should have been a public method in the first place.
da...@gmail.com <da...@gmail.com> #67
I couldn't have expressed it better. I fully agree to mikecon2... This is the root cause and history of the problem and simply needs to be corrected by a public method providing this basic file upload feature. I just hope that the Android developers are reading our comments as this issue is in closed status (?).
al...@gmail.com <al...@gmail.com> #68
When is this issue going to be fixed, this is a showstopper,it cant be left unsolved this long.
pb...@gmail.com <pb...@gmail.com> #69
My recommendation is to inform news sites about this KitKat upgrade problem. This problem affects thousands of Apps on the Google Play store and I'm pretty sure a lot of users would like to be informed about their installed Apps breaking when upgrading to Android 4.4.2
If for example Ars Technica could write something about this problem it would probably be fixed immediately.
If for example Ars Technica could write something about this problem it would probably be fixed immediately.
pb...@gmail.com <pb...@gmail.com> #70
Are you kidding me? This is an absolutely essential feature. I'd expect this to be broken in a legacy version, but this loss of critical functionality for an *upgrade* is pretty unexpected.. :(
en...@google.com <en...@google.com>
dr...@gmail.com <dr...@gmail.com> #71
Really helpless
ma...@gmail.com <ma...@gmail.com> #72
Hope this issue in WebView gets fixed at the earliest....Google devs, this is a must-have feature for the public API.
[Deleted User] <[Deleted User]> #73
It is surprising that the popularly used openFileChooser is not a part of public API. I'm sure many developers are desperately looking for a workable solution for this. While something gets done in an Android upgrade for this, it'll be great if someone can share any working work-around for this problem.
[Deleted User] <[Deleted User]> #74
For phonegap project, this plugin was shared here
https://github.com/cdibened/filechooser
Any other file chooser plugin can be used.
With that and the File Transfer plugin you can upload the files to the server
If you are not using phonegap then your work-around will need more work, you should create a way to execute the file chooser java code and a way to upload the files using java
Any other file chooser plugin can be used.
With that and the File Transfer plugin you can upload the files to the server
If you are not using phonegap then your work-around will need more work, you should create a way to execute the file chooser java code and a way to upload the files using java
[Deleted User] <[Deleted User]> #75
Any chance of seeing one of these band aided solutions incorporated into the code anytime soon?
ba...@gmail.com <ba...@gmail.com> #76
Has this still not been resolved? I have an app that relies on image file chooser and just won't work until this fix is implemented. I am absolutely disappointed in android development I literally had to do nothing for iOS because it was built in to webview but for android I have been pulling my hair out.
cw...@gmail.com <cw...@gmail.com> #77
Good news. Just had my Nexus 5 update to 4.4.3 and this issue now appears
fixed! My open FileChooser implementation which had been broken since 4.4.2
is working again!
fixed! My open FileChooser implementation which had been broken since 4.4.2
is working again!
bh...@gmail.com <bh...@gmail.com> #78
wasn't the kitkat webview supposed to autoupdate?
Even if they fixed it on 4.4.3, the problem will remain in devices that can't be updated
Even if they fixed it on 4.4.3, the problem will remain in devices that can't be updated
[Deleted User] <[Deleted User]> #79
I just tested 4.4.3 on my Nexus 7 device and the file chooser is now working as before but the file extension is not returned correctly in many cases. Can anyone else confirm this?
le...@gmail.com <le...@gmail.com> #80
[Comment deleted]
je...@gmail.com <je...@gmail.com> #81
I also tested on nexus 7 device with 4.4.3 updated,and file chooser is getting called but actual files like images are not getting uploaded.
I checked onpicpaste.com website with .jpg,.png images.
Is that issue of file extension not returned properly while uploading ?
I checked on
Is that issue of file extension not returned properly while uploading ?
Description
It seemed to operate more cleanly in previous version.