Bug 190982 - <input type=file accept=...> does not filter correct file types
Summary: <input type=file accept=...> does not filter correct file types
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari 12
Hardware: iPhone / iPad iOS 12
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-27 06:34 PDT by Khedron wilk
Modified: 2019-10-07 08:12 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Khedron wilk 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
Comment 1 Khedron wilk 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).
Comment 2 Nolan Lawson 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.
Comment 3 Chris Dumez 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?
Comment 4 Nolan Lawson 2019-10-07 03:52:47 PDT
Based on user reports (https://toot.cafe/@nolan/1029205644019006040) this is indeed fixed in iOS 13! :)
Comment 5 Khedron wilk 2019-10-07 04:36:36 PDT
Seems indeed to be solved in iOS 13.
So I close this bug.
Comment 6 Chris Dumez 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.