Given a web form with a file upload field with the accept attribute set to "*/*", like this:
<input type="file" accept="*/*">
Desktop browsers will ignore the accept attribute and allow any file to be uploaded. On iOS, however, this is not the case and instead of being given the equivalent experience (which would be the "Photo Library / Take Photo / Browse" menu), the user is dropped into the file browser but without the ability to actually select any files (they are grayed out).
Granted, "*/*" is not a valid accept value per the spec. However, based on searching google for "ios upload grayed out" it is clear that many sites are setting this attribute and causing problems for iOS users. This behavior is difficult to diagnose and inconsistent with the desktop experience.
This can be easily reproduced here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
"*/*" actually seems like a valid value according to the spec:
says "A valid MIME type string with no parameters"
which points to:
which points to:
media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token
type and subtype are both tokens, defined here:
so it seems like '*' is a valid token.
Ah, you're right, thanks!
Created attachment 436422 [details]
Comment on attachment 436422 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=436422&action=review
r=me with comment
> + if ([mimeType caseInsensitiveCompare:@"*/*"] == NSOrderedSame)
nit: Do we really need a caseInsensitiveCompare for "*/*"?
Created attachment 436425 [details]
(In reply to Chris Dumez from comment #5)
> Comment on attachment 436422 [details]
> View in context:
> r=me with comment
Thanks for the review!
> > Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm:358
> > + if ([mimeType caseInsensitiveCompare:@"*/*"] == NSOrderedSame)
> nit: Do we really need a caseInsensitiveCompare for "*/*"?
Uploaded a new patch using `isEqualToString:`.
Committed r281612 (240968@main): <https://commits.webkit.org/240968@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 436425 [details].
I just have to say, I'm really impressed with how quickly this bug was fixed. My first time cutting a WebKit issue and was expecting this to sit uncommented and then closed eventually for "no activity" or any of the other outcomes that seem common with large open-source projects supported by any of the Big 5. Very glad to be proven wrong.
My only complaints is that I was looking forward to figuring out WebKit development and fixing it myself :-)