Some File Extensions Inaccessible in File Browser Window

Hm... that's funny. I have personally never experienced that, but I'd say that it has something to do with Plupload library itself. Have you tried to ask in their issue queue?

It took a while to figure this out, but Drupal is providing the extensions probably. It's due to the plupload library. For the HTML5 runtime, it relies on a hardcoded list of mime type mappings. The HTML5 tag has an "accept" attribute that has to be mime types (text/plain, for example) - if you send it a list of file extensions, it processes that *inside* of the javascript against a map. If it has no match, it simply doesn't include it.

This looks like it has been "fixed" in plupload 2.x, by allowing users to provide their own additional mappings.

This is the official bug:
https://github.com/moxiecode/plupload/issues/526

This is a request and a workaround to add some more, and someone commented how they "sort of" got it in 1.x:
https://github.com/moxiecode/plupload/issues/721

Here's the comment about how 2.x now has the capability to add more:
https://github.com/moxiecode/plupload/issues/682#issuecomment-12321058

My psuedocode idea for the plupload 2.x library is something like:

// maybe this already has been included or exposed beforehand, would be nice to not have to re-run this just to get $mapping again.
if (!function_exists('file_mimetype_mapping)) {
 include_once DRUPAL_ROOT . '/includes/file.mimetypes.inc';
}
$mapping = file_mimetype_mapping();

$mime_types = '';
// for each of the file_extensions defined in the settings, record those in the $mime_types string used to feed to plupload's mapping Javascript
foreach (implode(' ', variable_get(' file_extensions', '')) as $extension) {
 if (isset($mapping['extensions'][$extension])) {
   $mime_types .= $mapping['mimetypes'][$mapping['extensions'][$extension]] . ' ' . $extension . ',';
 }
}
// trim off trailing comma
$mime_types = rtrim($mime_types, ',');
// Then make sure this is spit out in javascript somehow, BEFORE plupload is initialized, according to the docs
$javascript = 'mOxie.Mime.addMimeType(' . $mime_types . ');'; // this needs to be called before Plupload initialization

Hi,

I'm seeing what appears to be a very similar issue.

I've specified two acceptable file types for a field, then I'm using bulk_media_upload + Plupload to allow for a multiple file upload scenario. Like the original screenshot above, the two allowed file types are correctly listed below the Plupload widget but when I view files to associate with the field by using the Add files button, the dat files are being greyed out. Strangely, I can drag both dat files and cvs files onto the field and they will validate and upload just fine. In additional troubleshooting, I'm noticing that if change the acceptable file types for the field the following happens:

Valid types: CVS DAT | Add files listing shows only CVS files as acceptable and DAT files greyed out (broken behavior)
Valid types: CVS | Add files listing shows only CVS files as acceptable and DAT files greyed out (expected behavior)
Valid types: DAT | Add files listing shows all file types accessible - beyond even just CSV and DAT and including txt files, images, etc. - then when I select a non-valid type (anything but a DAT file), I get a dialog box opening to alert me that the file is of the wrong type. (inconsistent behavior)

What I'm noticing is that a CSV file is a valid MIME type and DAT is not and that when I test other valid MIME types I see the same results as above - essentially the condition which breaks is when there is a mixture of valid and invalid MIME types as acceptable file types for the field.

I had been using Plupload library version 1.5.4, but just updated to the latest stable 1.x version - 1.5.8 - and I'm not seeing any resolution. I'm using the latest module version: 1.7

I'm seeing the issue in both Chrome and Safari (WebKit), but not in Firefox.

This seems likely to be a Plupload bug rather than this module, but I'm hoping that someone with more domain expertise could assist in troubleshooting and confirm my suspicion.

Thanks!

Erik.