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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fuzzy76’s picture

Adding excerpt from the HTML5 spec for clarity:

The accept attribute may be specified to provide user agents with a hint of what file types will be accepted.

If specified, the attribute must consist of a set of comma-separated tokens, each of which must be an ASCII case-insensitive match for one of the following:

The string audio/*
Indicates that sound files are accepted.
The string video/*
Indicates that video files are accepted.
The string image/*
Indicates that image files are accepted.
A valid MIME type with no parameters
Indicates that files of the specified type are accepted.

quicksketch’s picture

Status: Active » Closed (duplicate)

This is the same as #877566: Opera 10.6 can upload not allowed file types. ImageField depends on FileField for creating the upload widget.

fuzzy76’s picture

That issue is actually something totally different, since it is about uploading filetypes not allowed (probably the javascript component failing).

quicksketch’s picture

Status: Closed (duplicate) » Active
quicksketch’s picture

Title: accept attribute contains extensions instead of mimetypes » Accept attribute contains extensions instead of mimetypes
Project: ImageField » FileField

Sorry 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.

toodlepip’s picture

Subscribing.

davebv’s picture

same problem here, subscribing

Pedro Lozano’s picture

Same 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

EvanDonovan’s picture

@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?

EvanDonovan’s picture

@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.

quicksketch’s picture

I 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.

jacobroufa’s picture

Any movement on this? Pretty annoying little bug...

bleen’s picture

subscribing

bleen’s picture

Status: Active » Needs review
FileSize
2.86 KB

This 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.

joelstein’s picture

Subscribing.

eatsleepdev’s picture

subscribing

Shai’s picture

I 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

Anonymous’s picture

Just 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)

bleen’s picture

cba110 ... 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

Rob_Feature’s picture

Consider this a vote for bookmarking on d.o (ie. 'just another subscribe post...')

omerida’s picture

#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.

quicksketch’s picture

but it would be nice to use the accept attribute correctly to prevent users from selecting unwanted file types in the first place

While 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.

junipllc’s picture

This 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.

bleen’s picture

junipllc: 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

EvanDonovan’s picture

End users expect extension lists; it's rather unfortunate that the HTML spec has left us with such an unhelpful attribute.

I 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....

Shai’s picture

In 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.

bleen’s picture

#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 ...

quicksketch’s picture

Thanks 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.

EvanDonovan’s picture

@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.

omerida’s picture

true, 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...

bleen’s picture

EvanDonovan’s picture

That got marked as a dupe of http://www.w3.org/Bugs/Public/show_bug.cgi?id=11482 which is now assigned to Ian Hickson.

brian_c’s picture

Ouch, this one is biting us hard too now.

Kinda seems like a violation of HTML5's "Support Existing Content" design principle. :/

jthomasbailey’s picture

Subscribing, strange that this wasn't a problem for me until at most four days ago. I wonder if Chrome updated itself in that time.

fuzzy76’s picture

brian_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.

carn1x’s picture

Subscribing

inlikealion’s picture

Subscribbling -_-

brian_c’s picture

Title: Accept attribute contains extensions instead of mimetypes (preventing Chrome from selecting files) » Accept attribute contains extensions instead of mimetypes
Status: Fixed » Needs review

It 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

jthomasbailey’s picture

Whichever, it would probably be faster to fix filefield than to lobby google to change it's browser.

brian_c’s picture

Absolutely, 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.

Bevan’s picture

kenneth@fiil.eu’s picture

Subscribing

thebuckst0p’s picture

Subscribe

quicksketch’s picture

bleen'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.

quicksketch’s picture

Title: Accept attribute contains extensions instead of mimetypes » Accept attribute contains extensions instead of mimetypes (preventing Chrome from selecting files)
Status: Needs review » Fixed

I 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.

Stefan Freudenberg’s picture

Just for the record: Until recently all browsers ignored that attribute according to http://www.w3schools.com/TAGS/att_input_accept.asp.

bleen’s picture

... but it didn't turn your site purple, right :)

So far all testing = works as advertised.

quicksketch’s picture

Thanks bleen18 :)

EvanDonovan’s picture

@Stefan: Checked SitePoint also, since that is more accurate - apparently it reports the same buggy support: http://reference.sitepoint.com/html/input/accept.

quicksketch’s picture

FileSize
811 bytes

I found that our extension checking is quite perfect in the new patch, I had to update it to support multiple extensions with this update.

scarvajal’s picture

Subscribing

vegardjo’s picture

Title: Accept attribute contains extensions instead of mimetypes » Accept attribute contains extensions instead of mimetypes (preventing Chrome from selecting files)
Status: Needs review » Fixed

Got 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! :)

Dashu’s picture

FileSize
19.44 KB

Hey 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

Dashu’s picture

FileSize
19.45 KB

woops.
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:

quicksketch’s picture

Guys, 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).

frob’s picture

So which patch is the fix?

quicksketch’s picture

#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.

frob’s picture

Cool thanks, I will wait until the next release if it is right around the corner.

casaswing’s picture

Thank you! Awaiting the updates.

timtunbridge’s picture

subscribe

quicksketch’s picture

New 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

geerlingguy’s picture

Thank goodness. I thought I was going insane, but I was just pointed here a few hours ago, and there's already an update!

slucas’s picture

Thanks 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

jlmeredith’s picture

For 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.

bleen’s picture

FYI ... 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

BenPoole’s picture

Status: Closed (fixed) » Fixed
Issue tags: -mac chrome, -upload file

Confirmed - I ran a pm-update (ver. 6.x-3.8 for both) on filefield and imagefield and the problem is resolved.

Bevan’s picture

If you can't upgrade for whatever reason, other workarounds include;

  • Use another browser
  • Remove the "Restrict file types" setting in the filefield. (This has security implications, so only do it if you trust anyone with permission to use the filefield
  • Dragging and dropping the file instead of selecting it from the file-browser (as above).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Bevan’s picture

reddyweb’s picture

Issue tags: +mac chrome, +upload file

Thank 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.

bleen’s picture

Status: Fixed » Closed (fixed)
Issue tags: +mac chrome, +upload file

For 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!!