RESOLVED FIXED 190982
<input type=file accept=...> does not filter correct file types 
https://bugs.webkit.org/show_bug.cgi?id=190982
Summary <input type=file accept=...> does not filter correct file types
Khedron wilk
Reported 2018-10-27 06:34:30 PDT
Not possible to specify correct file filter for file open dialog initated in a webpage view on webbrowser on IOS. The attribute ACCEPT on the HTML element INPUT with TYPE= ”file” is in IOS seems to not be interpreted according to official HTML standard as defined by W3C: Fo reference, please see: https://www.w3.org/TR/2018/SPSD-html401-20180327/interact/forms.html#file-select https://www.w3.org/TR/2018/SPSD-html401-20180327/types.html#type-content-type Steps to Reproduce: 1. Create a webpage that may produce a file dialog, like this example: <html> <body> <form action="nopage.html" method="post" enctype="multipart/form-data"> <label>File:</label> <input type="file" accept="image/png,image/jpeg,application/pdf"> <input type="submit" name="submit" value="Submit"> </form> </body> <html> 2. View the webpage built on this, or similar, code in a web browser on IOS. 3. Open the file dialog. Expected Results: When the file dialog windows is used to browse a file directory containing files of different types, all files of the types PNG, JPG and PDF should be selectable. No other file types should be selectable. Expected results in general is that selectable file types in a file dialog open from a webpage in this way should be according to the type specified in the accept attribute of the input element with type=file. Actual Results: When the file dialog windows is used to browse a file directory containing files of different types, only files of the types PNG ang JPG is selectable. Actual results in general is that the accept attribute, of the input element with type=file, does not result in the correct file types being selectable. Alternative actual results is that some combinations of types specified in accept attribute will result in alla files being selectable. Version/Build: IOS 11.3.1. IOS 12.0.1 Configuration/hardware+software: Mobile Safari on iPhone 7 (model MN952QB/A). Mobile Safari on iPad Pro 10 inch (model MQF22KN/A). Firefox Focus on iPhone 7 Firefox Focus on iPad Pro 10 inch. Possible related bugs (but not the same description/reasoning): 71858 https://bugs.webkit.org/show_bug.cgi?id=71858 This bug earlier reported in radar as: 40394436 https://bugreport.apple.com/web/?problemID=40394436
Attachments
Add attachment proposed patch, testcase, etc.
Khedron wilk
Comment 1 2018-10-28 00:19:26 PDT
Addendum: 1. My earlier tests seems to show that *no* other MIME-types than image/* works? No variant of application/ or other MIME-group seem to work. "Work" in this case = affect what files being selectable. "Earlier" in this case = IOS 11.x - I have not retested this specifically under IOS 12.x. 2. Personal speculation: I get association to the time before the Apple File-app was part of IOS. Before that you could only upload images. This looks to be some kind of remains of that time? 3. Since I am not a WebKit-developer I am not 100% sure whether this is a WebKit-bug or a IOS-bug. My apology if I am in error. 4. I am of course available as test user for any sort of testing related to this reported bug. 5. Real world consequences of this bug: There is web applications that a user today can not use in full on IOS. For security reasons an application may specify a narrow set of file types that are allowed to be uploaded to server. But since the accept-definition seems to not work correctly in WebKit/IOS the user are not able to upload some files that are needed for using the system. I.e. user have to interrupt their workflow on an iPhone/iPad to do some of the work on a traditional computer (laptop/desktop).
Nolan Lawson
Comment 2 2019-09-08 10:21:58 PDT
I believe I've run into the same issue. Here is a reproducible test case: http://bl.ocks.org/nolanlawson/raw/6fe0456c4b3996e69bbd1c2f11920d76/ On iOS 12.4, using <input type="file">, I see the following behavior: accept="audio/*" correctly allows m4a audio files to be selected accept="audio/*,image/*" does NOT allow m4a audio files to be selected accept="*/*" allows m4a audio files to be selected Steps to reproduce: 1. In the Voice Memos app, create a voice memo (m4a file) and save it to iCloud 2. Navigate to the above website in Safari 3. Click the "allows both audio and images" input 4. Under iCloud, try to choose the file Expected results: The m4a file is not grayed out and is selectable. Actual results: The m4a file is grayed out and not selectable.
Chris Dumez
Comment 3 2019-09-08 10:27:22 PDT
(In reply to Nolan Lawson from comment #2) > I believe I've run into the same issue. Here is a reproducible test case: > http://bl.ocks.org/nolanlawson/raw/6fe0456c4b3996e69bbd1c2f11920d76/ > > On iOS 12.4, using <input type="file">, I see the following behavior: > > accept="audio/*" correctly allows m4a audio files to be selected > accept="audio/*,image/*" does NOT allow m4a audio files to be selected > accept="*/*" allows m4a audio files to be selected > > Steps to reproduce: > > 1. In the Voice Memos app, create a voice memo (m4a file) and save it to > iCloud > 2. Navigate to the above website in Safari > 3. Click the "allows both audio and images" input > 4. Under iCloud, try to choose the file > > Expected results: > > The m4a file is not grayed out and is selectable. > > Actual results: > > The m4a file is grayed out and not selectable. I feel like I fixed this in iOS 13, could someone please try the beta?
Nolan Lawson
Comment 4 2019-10-07 03:52:47 PDT
Based on user reports (https://toot.cafe/@nolan/1029205644019006040) this is indeed fixed in iOS 13! :)
Khedron wilk
Comment 5 2019-10-07 04:36:36 PDT
Seems indeed to be solved in iOS 13. So I close this bug.
Chris Dumez
Comment 6 2019-10-07 08:12:38 PDT
(In reply to Khedron wilk from comment #5) > Seems indeed to be solved in iOS 13. > So I close this bug. Thanks for confirming.
Note You need to log in before you can comment on or make changes to this bug.