Bug 51457

Summary: [EFL] Return an empty string instead of 'application/octet-stream' in getMIMETypeForExtension()
Product: WebKit Reporter: Gyuyoung Kim <gyuyoung.kim>
Component: WebKit EFLAssignee: Gyuyoung Kim <gyuyoung.kim>
Status: RESOLVED FIXED    
Severity: Normal CC: antognolli+webkit, commit-queue, kenneth, leandro, lucas.de.marchi, tonikitoo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
Patch
none
Patch none

Description Gyuyoung Kim 2010-12-22 02:47:03 PST
WebKit EFL can't play html5 audio now. I look into WebCore in order to find the reason. When MediaPlayer loads content via url, it checks mediaType with file extension. But, if getMIMETypeForExtension() of MIMETypeRegistryEfl.cpp cannot find same mime type with the extension, it returns "application/octet-stream".

String MIMETypeRegistry::getMIMETypeForExtension(const String &ext)
{
    String s = ext.lower();
    const ExtensionMap *e = extensionMap;
    while (e->extension) {
        if (s == e->extension)
            return e->mimeType;
        ++e;
    }

    return "application/octet-stream";
}

But, if the getMIMETypeForExtension() of MIMETypeRegistryEfl.cpp cannot find appropriate mime type, getMIMETypeForExtension() of MIMETypeRegistry.cpp tries to find mime type in mediaMIMETypeMap() of MIMETypeRegistry.cpp.

Unfortunately, HTML5 Audio doesn't be played in WebKit EFL because getMIMETypeForExtension() of MIMETypeRegistryEfl.cpp returns "application/octet-stream".

String MIMETypeRegistry::getMediaMIMETypeForExtension(const String& ext)
{
    // Look in the system-specific registry first.
    String type = getMIMETypeForExtension(ext);
    if (!type.isEmpty())
        return type;

    Vector<String>* typeList = mediaMIMETypeMap().get(ext);
    if (typeList)
        return (*typeList)[0];
    
    return String();
}

So, I change the "application/octet-stream" with "String()". Below demo sites can be worked based on this patch.
 - http://moztw.org/demo/audioplayer/
 - http://www.scottandrew.com/pub/html5audioplayer/
Comment 1 Gyuyoung Kim 2010-12-22 02:54:42 PST
Created attachment 77199 [details]
Patch
Comment 2 Antonio Gomes 2010-12-22 06:17:28 PST
Is it what other ports do?

(On the airport now, and can not check myself at the moment)
Comment 3 Gyuyoung Kim 2010-12-22 16:08:10 PST
(In reply to comment #2)
> Is it what other ports do?
> 
> (On the airport now, and can not check myself at the moment)

Yes, other port also tries to find mime type for the extension type. But, if it cannot find mime type, it just returns empty string. Then, if the other port's getMIMETypeForExtension() returns empty string, the getMediaMIMETypeForExtension() of MIMETypeRegistry.cpp finds a proper mime type in mediaMIMETypeMap() for the extension. (The mediaMIMETypeMap() is defined in MIMETypeRegistry.cpp).

In MIMETypeRegistryGtk.cpp

    String MIMETypeRegistry::getMIMETypeForExtension(const String &ext)
    {
        String s = ext.lower();
        const ExtensionMap *e = extensionMap;
        while (e->extension) {
            if (s == e->extension)
                return e->mimeType;
            ++e;
        }

        return String();
    }

In MIMETypeRegistryQt.cpp

    String MIMETypeRegistry::getMIMETypeForExtension(const String &ext)
    {
        String s = ext.lower();

        const ExtensionMap *e = extensionMap;
        while (e->extension) {
            if (s == e->extension)
                return e->mimeType;
            ++e;
        }

        return String();
    }

In MIMETypeRegistryWinCE.cpp

    String MIMETypeRegistry::getMIMETypeForExtension(const String &ext)
    {
        if (ext.isEmpty())
            return String();

        initMIMETypeEntensionMap();

        String result = mimetypeMap.get(ext.lower());
        if (result.isEmpty()) {
            result = mimeTypeForExtension(ext);
            if (!result.isEmpty())
                mimetypeMap.add(ext, result);
        }
        return result.isEmpty() ? "unknown/unknown" : result;
    }
Comment 4 Eric Seidel (no email) 2010-12-23 01:16:00 PST
Comment on attachment 77199 [details]
Patch

Tests should be layout tests.  Does EFL run the layout tests yet?
Comment 5 Gyuyoung Kim 2010-12-23 01:58:09 PST
(In reply to comment #4)
> (From update of attachment 77199 [details])
> Tests should be layout tests.  Does EFL run the layout tests yet?

Yes, right. WebKit EFL doesn't have layout test yet. But, we are preparing to contribute DRT for WebKit EFL.
Comment 6 Gyuyoung Kim 2010-12-23 03:20:07 PST
Should I remove the test sites in ChangeLog ?
Comment 7 Gyuyoung Kim 2010-12-23 15:23:15 PST
Created attachment 77375 [details]
Patch

Remove test sites in ChangeLog
Comment 8 WebKit Commit Bot 2010-12-24 03:23:31 PST
Comment on attachment 77375 [details]
Patch

Clearing flags on attachment: 77375

Committed r74625: <http://trac.webkit.org/changeset/74625>
Comment 9 WebKit Commit Bot 2010-12-24 03:23:38 PST
All reviewed patches have been landed.  Closing bug.