1240259 - audio ogg file has type 'video/ogg' instead of 'audio/ogg' in several scenarios

Status: UNCONFIRMED

(Core :: DOM: File, defect, P3)

Description

[Naomi Aro]

Attachment: ACDC_-_Back_In_Black-sample.ogg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

Firefox 43.0.4
MacOSX 10.11.1

Was dropping the attached file into a div with an ondrop event, something like this:

for (var i = 0; i < e.dataTransfer.files.length; i++) {
    this.fire("newtrack", e.dataTransfer.files[i]) // <-- problem with files in this list.
}


Actual results:

File object had type 'video/ogg'


Expected results:

File object should have type 'audio/ogg'

-Chrome gives this type, and also my system info.

Comment 1

[Loic]

Could you attach the small html testcase to drop the ogg, please.

Comment 2

[Naomi Aro]

(In reply to Loic from comment #1)
> Could you attach the small html testcase to drop the ogg, please.

Sure, I'll just create a self contained one in a moment

Comment 3

[Naomi Aro]

Attachment: html example

This html example prints dropped files to the console. You'll see the 'video/ogg' type.

Comment 4

[Elliot Bentley]

I'd like to add that this bug also appears to affect ogg audio files accessed via a file type input element.

Comment 5

[woranl]

In Chrome, if I load an ogg video with .ogg extension instead of .ogv, it will incorrectly return a file type of audio/ogg instead of video/ogg.  It appears that Firefox default .ogg as video file, while Chrome default .ogg as audio file.

Comment 6

[woranl]

Attachment: Xacti-AC8EX-Sample_video-001.ogg

Comment 7

[Loic]

baku, do you know why there is a difference between Chrome et Firefox.
Is Firefox wrong with the .ogg MIME type?

Comment 8

[woranl]

From: https://en.wikipedia.org/wiki/Ogg

The Ogg container format can multiplex a number of independent streams for audio, video, text (such as subtitles), and metadata... Before 2007, the .ogg filename extension was used for all files whose content used the Ogg container format. Since 2007, the Xiph.Org Foundation recommends that .ogg only be used for Ogg Vorbis audio files. The Xiph.Org Foundation decided to create a new set of file extensions and media types to describe different types of content such as .oga for audio only files, .ogv for video with or without sound (including Theora), and .ogx for multiplexed Ogg.

Also see https://wiki.xiph.org/MIME_Types_and_File_Extensions

Firefox is likely wrong with the .ogg MIME type.

Comment 9

[Andrea Marchesini [:baku]]

File object uses nsIMIMEService to retrieve the mime type, but this component just uses the extension:

https://dxr.mozilla.org/mozilla-central/source/netwerk/mime/nsIMIMEService.idl#54

     * Retrieves a ACString representation of the MIME type
     * associated with this URI. The association is purely
     * file extension to MIME type based. No attempt to determine
     * the type via server headers or byte scanning is made.

Unfortunately File.type is sync and we don't want to do blocking I/O on the main-thread.

Comment 10

[Andrea Marchesini [:baku]]

mystor, do you think it's possible to propagate the mime-type sent by the OS up to the File object, somehow?
Maybe we can extend  File::CreateFromFile to receive the contentType.

Comment 11

[Nika Layzell [:nika] (ni? for response)]

(In reply to Andrea Marchesini [:baku] from comment #10)
> mystor, do you think it's possible to propagate the mime-type sent by the OS
> up to the File object, somehow?
> Maybe we can extend  File::CreateFromFile to receive the contentType.

I imagine that this would be possible to do this. From my quick look it appears as though there is a method available to create dom::File objects with explicit content types with an overload of File::CreateFromFile(nsISupports*, nsIFile*, const nsAString&, const nsAString&); Unfortunately, we don't have any easy path to propagate that data by, as the data which we receive from our OS-agnostic wrapper just gives us a nsIFile.

The data in the DataTransfer is fetched from the OS here: http://searchfox.org/mozilla-central/rev/3f614bdf91a2379a3e2c822da84e524f5e742121/dom/events/DataTransferItem.cpp#175, and then the file is retrieved by accessing the data labeled "application/x-moz-file". For example, as far as I can tell the nsIFile object is created on linux here: http://searchfox.org/mozilla-central/rev/3f614bdf91a2379a3e2c822da84e524f5e742121/widget/gtk/nsDragService.cpp#796-828. 

The easiest solution would probably be to also perform the file IO required to get the OS-provided mime-type when filling in external data within DataTransferItem::FillInExternalData. Within this method we already perform blocking mainthread IO to load data from the clipboard IIRC. I'm not sure if that would be an acceptable solution. What do you think :baku?

Comment 12

[Andrea Marchesini [:baku]]

Actually, a similar issue happens with HTMLInputElement when a ogg file is selected, with Directory Upload API and with Entries API. Probably we should fix it in a more generic way and not just for D&D.

Comment 13

[7t3chguy]

Shouldn't this be in DOM: File?

Comment 14

[nonopewho]

It seems to change with every update. I had an extension work completely fine until the most recent update, where it started doing this.