Created attachment 47860 [details] Flidget2.zip Steps to Reproduce: 1) Launch QtLauncher. 2) Extract contents of Flidget2.zip. 3) Load Flidget.html from the extracted files. 4) Open Image File: input field. 5) Open Video File: input field. 6) Open Audio File: input field. Expected: R1: The select file should only show images. R2: The select file dialog should only show videos. R3: The select file dialog should only show music. Actual: The Select dialog shows all files.
Please follow the QtWebKit bug reporting guidelines when reporting bugs. See http://trac.webkit.org/wiki/QtWebKitBugs Specifically: - The 'QtWebKit' component should only be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit http://trac.webkit.org/wiki/QtWebKitBugs#Component - Add the keyword 'Qt' to signal that it's a Qt-related bug http://trac.webkit.org/wiki/QtWebKitBugs#Keywords
I believe this is not specific to the Qt port: http://www.w3schools.com/TAGS/att_input_accept.asp: "The accept attribute is not properly supported by any of the major browsers." http://htmlhelp.com/reference/html40/forms/input.html: "Current browsers generally ignore the ACCEPT attribute." Suggest removing the Qt tag and setting the component to Forms.
(In reply to comment #2) > I believe this is not specific to the Qt port: > http://www.w3schools.com/TAGS/att_input_accept.asp: "The accept attribute is > not properly supported by any of the major browsers." > http://htmlhelp.com/reference/html40/forms/input.html: "Current browsers > generally ignore the ACCEPT attribute." > > Suggest removing the Qt tag and setting the component to Forms. Sounds reasonable.
Created attachment 415400 [details] Three file input with the three various forms of "pick all" values; "audio/*", "video/*", "image/*"
Created attachment 415402 [details] mp3 and m4a files disabled in a iCloud Drive view from a file input with accept="audio/*"
Created attachment 415404 [details] Four file input with four forms of accept attributes: "audio/*", ".mp3,.m4a", "video/*", "image/*"
Created attachment 415405 [details] replay of "audio/*" and ".mp3,.m4a" file inputs being used
Hello! This seems to have been forgotten. Our team just hit a weird thing related to this. We have an app that lets users distribute recordings. All was fine, until a colleague tried to select a mp3 file on iOS Safari. The input field has the accept attribute set to "audio/*", but he was not able to select neither a mp3 nor m4a file from his iCloud Drive. See https://bug-34442-attachments.webkit.org/attachment.cgi?id=415402 for a screenshot. His device: iPhone 12 Pro, with iOS 14.2.1. So we tried to research what this could be. We found some various hits on stackoverflow, but nothing addressed to exactly this. Caniuse was of little help as well: https://caniuse.com/input-file-accept There it says iOS Safari (versions 8 - 13.7, 14.2) "Supports the type format (e.g. image/*) but not the extension format (e.g. .png)", which is the opposite of what we're experiencing. Because it worked as expected when we set accept to ".mp3,.m4a"... See the replay at https://bug-34442-attachments.webkit.org/attachment.cgi?id=415405 for it in action. The minimal HTML showcasing can be seen at https://bug-34442-attachments.webkit.org/attachment.cgi?id=415404 https://output.jsbin.com/yilametaki or just inline: ``` <style> label { display: block; margin: 16px; } </style> <label> accept="audio/*" <input type="file" accept="audio/*"> </label> <label> accept=".mp3,.m4a" <input type="file" accept=".mp3,.m4a"> </label> <label> accept="video/*" <input type="file" accept="video/*"> </label> <label> accept="image/*" <input type="file" accept="image/*"> </label> ```
Hey Matthias, I'm quite new to Bugzilla. I hoped from some input from you, as you worked on the date input, it seemed like, and you got experience with this. I followed that bug, and was glad to see it finally happening. So I wanted to tag you in this for some input, but I'm not sure that adding you manually to the CC list is the way to go. Please tell me so. Should I create a new bug, or is it fine to use this 10(!) year old?
Hi Ole, > you worked on the date input No, I did not work on the date input. I just added a couple of comments, but nothing more. I never hacked the webkit source code. Sorry. > Should I create a new bug, or is it fine to use this 10(!) year old? Not sure. Do you plan to provide a patch? I think I am the wrong person to address. As said, I just follow bugs, comment on them, but nothing more.
Aha, my bad! Thanks for the reply anyway :) No plans on providing a patch, as I don't even have a device to test this myself.
Hey Aditya! Sneakily added you to the CC list, hoping you might be able to provide an answer to both... < ... > So I wanted to tag you in this for some input, but I'm not sure that adding > you manually to the CC list is the way to go. Please tell me so. > > Should I create a new bug, or is it fine to use this 10(!) year old?
(In reply to Ole Strøm from comment #12) > Hey Aditya! > > Sneakily added you to the CC list, hoping you might be able to provide an > answer to both... > > < ... > > So I wanted to tag you in this for some input, but I'm not sure that adding > > you manually to the CC list is the way to go. Please tell me so. > > > > Should I create a new bug, or is it fine to use this 10(!) year old? Hi Ole! Adding me to the CC list is fine. I think a new bug would be better, since the bug you're experiencing appears appears specific to iOS and "audio/*" in the accept attribute. (I verified that "video/*" and "image/*" work as intended).
I'm hitting this issue on iOS 14.5. The problem is the following: <input type="file" accept=".custom"> makes Safari accept any file. <input type="file" accept=".custom,.json"> makes Safari accept only .json files, but not .custom files. CanIUse (https://caniuse.com/input-file-accept) is indeed not 100% correct it seems, as outlined in https://bugs.webkit.org/show_bug.cgi?id=34442#c8.
Safari on desktop, however, works as expected.