Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Chrome (developer version, but I suspect the code will find its way into the stable releases if it haven't already) for OS X has a strict handling of the accept attribute on filefields, meaning it only check the contents against mimetypes per the HTML5 spec. This means that it will not allow me to (for instance) upload files with a mimetype of image/jpeg because it doesn't match against "jpeg" alone. This completely breaks imagefields on newer browsers, preventing me from selecting any images at all.
Comment | File | Size | Author |
---|---|---|---|
#54 | filefield_mimetype_fix.patch | 19.45 KB | Dashu |
#53 | filefield_mimetype_fix.patch | 19.44 KB | Dashu |
#50 | filefield_extension_fix.patch | 811 bytes | quicksketch |
#44 | filefield_replace_accept_attribute.patch | 4.38 KB | quicksketch |
#14 | extensions.patch | 2.86 KB | bleen |
Comments
Comment #1
fuzzy76 CreditAttribution: fuzzy76 commentedAdding excerpt from the HTML5 spec for clarity:
Comment #2
quicksketchThis is the same as #877566: Opera 10.6 can upload not allowed file types. ImageField depends on FileField for creating the upload widget.
Comment #3
fuzzy76 CreditAttribution: fuzzy76 commentedThat issue is actually something totally different, since it is about uploading filetypes not allowed (probably the javascript component failing).
Comment #4
quicksketchComment #5
quicksketchSorry you're correct, I'm not sure what made me think they were the same. Let's move this over to the FileField queue, since it's responsible for rendering the field and the JavaScript used to validate the file type.
Comment #6
toodlepip CreditAttribution: toodlepip commentedSubscribing.
Comment #7
davebv CreditAttribution: davebv commentedsame problem here, subscribing
Comment #8
Pedro Lozano CreditAttribution: Pedro Lozano commentedSame problem, very annoying, having to open firefox every time I have to attach an image.
This is also been worked in D7 #939962: File field allowed extensions JS broken in Chrome on OS X
Comment #9
EvanDonovan CreditAttribution: EvanDonovan commented@quicksketch: Now that this has become a core bug (for D7), and was marked critical over there by the people reporting the issue, do you have any insight into the best way to fix this? If there were a function that had an array matching extensions to mime types, and they were output as mime types to the client, would that cause issues for older browsers?
Comment #10
EvanDonovan CreditAttribution: EvanDonovan commented@quicksketch: I downgraded the D7 issue to major since that was the priority over here (and it's not "system-breaking", in the sense of breaking Drupal overall for a large percentage of users). I also outlined 4 options for how to fix it though: http://drupal.org/node/939962#comment-3651130. I would appreciate your insight as to which would be best.
Comment #11
quicksketchI posted a solution over in #939962: File field allowed extensions JS broken in Chrome on OS X, though of course it will need to be ported to D6 for our use in FileField.
Comment #12
jacobroufa CreditAttribution: jacobroufa commentedAny movement on this? Pretty annoying little bug...
Comment #13
bleen CreditAttribution: bleen commentedsubscribing
Comment #14
bleen CreditAttribution: bleen commentedThis is a backport of the patch that quicksketch put together at #939962-16: File field allowed extensions JS broken in Chrome on OS X ...
I'm pretty sure there is a more elegant way to add the accepted filetypes to some javascript variable, but I'm tired. In any case, this works in the same way that qucksketch's patch does: we kill the "accepted" attribute all together, and rely on javascript to handle the validation.
Comment #15
joelstein CreditAttribution: joelstein commentedSubscribing.
Comment #16
eatsleepdev CreditAttribution: eatsleepdev commentedsubscribing
Comment #17
Shai CreditAttribution: Shai commentedI confirmed, on a D6 site running Filefield 3.7, that I was not able to upload a an image to an imagefield using Chrome-for-Mac v. 8.0.552.208 beta.
I applied the patch. The patch applied cleanly.
After I applied the patch from #14. I was able to upload an image using the same Chrome-for-Mac browser.
I did not attempt to evaluate the elegance of the code :), just that it works.
Shai
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedJust to let you guys know. Was able to select and upload files within Chrome until yesterday when I installed the transliteration module. After this the problem appeared. Perhaps transliteration is having an effect that prevents people to select files to upload on Drupal via Chrome. I also found another person that pointed this same issue at a different discussion at "http://drupal.org/node/953922" comment number #7. Any help would be greatly appreciated.
This problem only occurs on Chrome (I'm using the latest version 8.0.552.215 for Mac)
Comment #19
bleen CreditAttribution: bleen commentedcba110 ... the exact cause of this issue is known: Chrome has started handling the HTML5 spec correctly when it comes to the "accepts" attribute. That spec expects MIME types instead of file extensions.
The fix can be found in #14, although I still need some code reviewers...
I doubt very much that transliteration had anything to do with you seeing this issue unless it updated your version of chrome and/or modified one of your file fields
Comment #20
Rob_Feature CreditAttribution: Rob_Feature commentedConsider this a vote for bookmarking on d.o (ie. 'just another subscribe post...')
Comment #21
omerida CreditAttribution: omerida commented#14 applied and fixed it for me, but it would be nice to use the accept attribute correctly to prevent users from selecting unwanted file types in the first place.
Comment #22
quicksketchWhile that would be nice, that means you'd need to ask the administrator setting up the field for the list of MIME types that are acceptable. While this may be somewhat clear for images (image/png for example), it'd be pretty much impossible to give accurate MIME type for something like a Word (.docx) document, which has the MIME type "application/vnd.openxmlformats-officedocument.wordprocessingml.document". End users expect extension lists; it's rather unfortunate that the HTML spec has left us with such an unhelpful attribute.
Comment #23
junipllc CreditAttribution: junipllc commentedThis suddenly started happening to me as well. Oddly enough, this wasn't a problem for me when the thread started, just in the past few days. All of my software has been up to date, I believe, and it was definitely working fine throughout October and November.
Problem is the same: one of my sites will no longer allow me to upload files (e.g. image files) despite the file being allowed in the extensions list. The dialog just has grayed out files.
I'm running the 8.0.552.215 build of Chrome for Mac (10.6).
I have not applied #14 (yet). Should I just apply the patch to my network of sites, or is there a forthcoming release that fixes the problem? Is there anything you need in order to facilitate an updated release that I can help with?
Also, does anybody know when this actually started happening? I have no idea why I'd be just seeing it now when this thread is more than two months old.
Lots of questions, I know, but I'm befuzzled.
Comment #24
bleen CreditAttribution: bleen commentedjunipllc: The next step is for some people to look closely at the code in #14 and decide if it is good to go or if it needs some changes. You *can* apply this to your sites, but it is not recommended that you play with patches on production sites.
If you'd like to help get this patch committed, then you can review the code in #14 and give your opinion about wether it's ready to go or at least apply the patch in #14 and confirm that it works as advertised (with no detrimental side effects).
Once this code is reviewed and tested (or alternate code is reviewed & tested) then I'm sure that one of the maintainers will commit it and it will be part of the subsequent release...
As for when this started, I'm not sure exactly when this happened, but I know it was at different times for Chrome 9 (beta) and Chrome 8
Comment #25
EvanDonovan CreditAttribution: EvanDonovan commentedI wonder if the WHATWG/W3C could be persuaded to change/add to the accept attribute properties at this time. I think HTML5 is not yet finalized yet....
Comment #26
Shai CreditAttribution: Shai commentedIn response, to @junipllc, I just want to add a bit of nuance to what @bleen18 regarding said, "it is not recommended that you play with patches on production sites." That's true, but sometimes in the real world you have to do what isn't recommended. It's certainly recommended to not patch the module but rather add some help text to the upload form (which you can do via the UI for the field in question), that would say, "File uploading is not working in Chrome 8, 9, etc... whatever browsers are not working, please use a different browser."
For some clients, however, that just may not be acceptable. As long as you explain the risks to the client and can monitor the site closely and have your codebase under version control, then it is a "reasonable" thing to patch a production site.
As for a solution being committed to "dev" it could be 3 days from now or three months, depending on whether people step to the plate to review and test the current proposed patch. For the solution to be committed to stable release (Filefield "3.8") my guess is it will be soon after the solution is committed to dev. @quicksketch is the best they come in terms of module maintenance.
Comment #27
bleen CreditAttribution: bleen commented#25: How does one petition the W3C?
#26: Yes, Shai is absolutely correct. If you *have* to apply the patch in 14, then do so (just be diligent about testing any related code/modules that you may have installed.) Also, if you do apply the patch in 14, report back on this thread with either "Wow, it works great" or "Holy crap, this made my entire site turn purple" or ...
Comment #28
quicksketchThanks for the helpful (and humorous) feedback guys. ;)
I'm going through the whole FileField queue now so I hope to get to this one soon. Usually it takes me about a week to get through a module's queue and make a new release, so Chrome users can look for an official fix soon.
Comment #29
EvanDonovan CreditAttribution: EvanDonovan commented@bleen18: I think Everett Zufelt is the best person to ask. He has done so in the past w/r/t ARIA, I think. I think that you can add comments into the spec on the WHAT-WG site though.
Comment #30
omerida CreditAttribution: omerida commentedtrue, it would be a pain to expect users to provide mimetypes. In that case, you'd want something underneath that translates file extensions to mime types. Maybe using http://api.drupal.org/api/drupal/includes--file.inc/function/file_get_mi...
Comment #31
bleen CreditAttribution: bleen commented#25/#27/#29 : http://www.w3.org/Bugs/Public/show_bug.cgi?id=11481
Comment #32
EvanDonovan CreditAttribution: EvanDonovan commentedThat got marked as a dupe of http://www.w3.org/Bugs/Public/show_bug.cgi?id=11482 which is now assigned to Ian Hickson.
Comment #33
brian_c CreditAttribution: brian_c commentedOuch, this one is biting us hard too now.
Kinda seems like a violation of HTML5's "Support Existing Content" design principle. :/
Comment #34
jthomasbailey CreditAttribution: jthomasbailey commentedSubscribing, strange that this wasn't a problem for me until at most four days ago. I wonder if Chrome updated itself in that time.
Comment #35
fuzzy76 CreditAttribution: fuzzy76 commentedbrian_c, not really. Existing content generally does not consist of this misuse of the accept attribute. This is due to filefield outputting clearly invalid code, something it never should have done to begin with.
I agree that using mimetypes for this is a terrible choice. I would have loved to use file extensions instead. But I fear getting changes in is a bit too late. The behaviour of the ACCEPT attribute on input elements has been set since the first HTML 4 draft from 1997. The behaviour was also mentioned (though not mandated) even in the HTML 3.0 spec from 1995.
Lobbying for Webkit (or HTML5 for that matter) to break a 15+ year old standard is just silly IMHO.
Comment #36
carn1x CreditAttribution: carn1x commentedSubscribing
Comment #37
inlikealion CreditAttribution: inlikealion commentedSubscribbling -_-
Comment #38
brian_c CreditAttribution: brian_c commentedIt seems that browsers have historically accepted this usage before, and it seems reasonable to assume a lot of code out there makes use of that fact, IMHO.EDIT: I stand corrected, browsers did not accept this usage before, they simply ignored it. Rendering my entire post off-base. :P
Comment #39
jthomasbailey CreditAttribution: jthomasbailey commentedWhichever, it would probably be faster to fix filefield than to lobby google to change it's browser.
Comment #40
brian_c CreditAttribution: brian_c commentedAbsolutely, Drupal needs to support mimetypes (via file_get_mimetype() as per #30?) for the accept field, as both a matter of immediate practicality and following spec & best practices.
Sorry to wax philosophical.
Comment #41
Bevan CreditAttribution: Bevan commentedI filed a bug report in the chromium/chrome issue queue about this.
Comment #42
kenneth@fiil.eu CreditAttribution: kenneth@fiil.eu commentedSubscribing
Comment #43
thebuckst0p CreditAttribution: thebuckst0p commentedSubscribe
Comment #44
quicksketchbleen's patch in #14 definitely made progress towards fixing the problem, but I found that it wouldn't work with multiple values when you clicked the "more" button, since that adds additional fields to the page that weren't present before. In D7 we have a better AJAX system that actually returns the additional settings necessary to identify the new fields, but in D6 we'll just have to work with the name of the field that exists when the page is loaded, rather than using IDs.
This patch is probably a little larger than it needs to be since it moves some of our JS code around for consistency, but it fixes the problem and works with multiple values.
Comment #45
quicksketchI went ahead and committed this since it clears up the problem. I still have to go through the ImageField queue before releasing 3.8 versions of both modules. Please try out the dev version of FileField (or do a CVS checkout) in the mean time until 3.8 is released.
Comment #46
Stefan Freudenberg CreditAttribution: Stefan Freudenberg commentedJust for the record: Until recently all browsers ignored that attribute according to http://www.w3schools.com/TAGS/att_input_accept.asp.
Comment #47
bleen CreditAttribution: bleen commented... but it didn't turn your site purple, right :)
So far all testing = works as advertised.
Comment #48
quicksketchThanks bleen18 :)
Comment #49
EvanDonovan CreditAttribution: EvanDonovan commented@Stefan: Checked SitePoint also, since that is more accurate - apparently it reports the same buggy support: http://reference.sitepoint.com/html/input/accept.
Comment #50
quicksketchI found that our extension checking is quite perfect in the new patch, I had to update it to support multiple extensions with this update.
Comment #51
scarvajal CreditAttribution: scarvajal commentedSubscribing
Comment #52
vegardjo CreditAttribution: vegardjo commentedGot this one too after Chrome was updated to 8. When I applied the patch in #44 I got to select a file in the finder (which I didn't before), but when I clicked the upload button I got the following error:
"The selected file C:\fakepath\CIMG2817.JPG cannot be uploaded. Only files with the following extensions are allowed: png gif jpg jpeg."
I'm on a Mac so there is no C:\ nor any fakepath anywhere in my system, however after applying patch in #50 as well this went away and filefield works again - have tested with multiple uploads of images on an imagefield and multiple mp3 files on a plain filefield - so thanks! :)
Comment #53
Dashu CreditAttribution: Dashu commentedHey guys,
I found myself facing the problem today while working a project.
After some looking I decided to alter the filefield code (basically, because I couldnt find a hook to alter the accept field).
I decided to publish my patch, here is what it does:
everytime a filefield is printed and the accept field is constructed, my patch gets the right mimetypes for the file extensions and adds them to the accept field (instead of the file extensions).
Now in the javascript, if you have chosen a file. It gets the file extension, checks the mimetype and if its in the list of allowed mime types and errors if not.
Note 1:
I'm using Drupal6 and Filefield 6.x-3.7
Note 2:
since I cant use the original chosen file extensions in the error message, I have to extract the file extensions from the mime types. This sometimes results in more file extensions shown thatn you have listed.
Example:
in my imagefield I restricted the image to only allow:
png jpg jpeg
which results in mimetypes image/png and image/jpeg.
When I resolve the mimetypes to the supported file extensions it gets "jpeg, jpg, jpe, png".
Feel free to enhance my code. :)
Greets,
Dennis
Comment #54
Dashu CreditAttribution: Dashu commentedwoops.
There was a uncommitted bugfix for a problem with irregularly cased letters in file extensions.
Thought I committed it, so here's a version with a bugfix now:
Comment #55
quicksketchGuys, this is already fixed, we don't need any more patches. While actually using MIME types is an interesting possibility, it'd probably be better to think about it in a new issue (as a feature request instead of a bug).
Comment #56
frobSo which patch is the fix?
Comment #57
quicksketch#44 and then #50. I suggest just downloading the dev version at this point or waiting for 3.8, which should be out within the next few days.
Comment #58
frobCool thanks, I will wait until the next release if it is right around the corner.
Comment #59
casaswing CreditAttribution: casaswing commentedThank you! Awaiting the updates.
Comment #60
timtunbridge CreditAttribution: timtunbridge commentedsubscribe
Comment #61
quicksketchNew 3.8 versions are now out. Please install both FileField and ImageField 3.8 at the same time.
Release notes
FileField: http://drupal.org/node/994994
ImageField: http://drupal.org/node/995024
Comment #62
geerlingguy CreditAttribution: geerlingguy commentedThank goodness. I thought I was going insane, but I was just pointed here a few hours ago, and there's already an update!
Comment #63
slucas CreditAttribution: slucas commentedThanks for this new version, but it doesn't apear in drush pm-update or through the admin/reports/updates/list page.
Now it apear, so no more problem. Thanks
Comment #64
jlmeredithFor those that cannot update to the dev version, there is a work around for this.
You can drag and drop from the finder on to the icon and it will stage the file for upload.
Comment #65
bleen CreditAttribution: bleen commentedFYI ... this is now part of a full release FileField 6.x-3.8 so there is no need to update to any dev version of FileField
Comment #66
BenPoole CreditAttribution: BenPoole commentedConfirmed - I ran a pm-update (ver. 6.x-3.8 for both) on filefield and imagefield and the problem is resolved.
Comment #67
Bevan CreditAttribution: Bevan commentedIf you can't upgrade for whatever reason, other workarounds include;
Comment #69
Bevan CreditAttribution: Bevan commentedChromium/Chrome buggy handling of invalid
type=""
attributes has also been fixed.Comment #70
reddyweb CreditAttribution: reddyweb commentedThank you. This patch (#14) working fine for me.
Actually the issue is, If we give Allowed Extensions: like 'pdf, ppt, doc' for upload field, MAC - Chrome 8.0 doesn't allow me to any upload file. But if we won't give any allowed extensions for upload field might need not to be apply this patch.
So after applying this patch (#14) it has been working fine for me.
Comment #71
bleen CreditAttribution: bleen commentedFor future reference the HTML5 spec has just been changed to allow both extensions AND mime types in the "accept" attribute.
http://html5.org/tools/web-apps-tracker?from=7056&to=7057
This was added to the spec because of this issue on D.O. :) see #31 above.
YAY!!