Bug 93345 - [EFL] Unskip fast/dom/HTMLLinkElement/subresource.html
Summary: [EFL] Unskip fast/dom/HTMLLinkElement/subresource.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Gyuyoung Kim
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-07 01:41 PDT by Gyuyoung Kim
Modified: 2012-08-07 16:54 PDT (History)
4 users (show)

See Also:


Attachments
Patch (2.06 KB, patch)
2012-08-07 11:31 PDT, Gyuyoung Kim
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gyuyoung Kim 2012-08-07 01:41:00 PDT
Though LINK_PREFETCH feature is enabled, fast/dom/HTMLLinkElement/subresource.html is still failed because of below difference,

- prefetch.link has MIME type application/octet-stream
+ prefetch.link has MIME type text/plain
Comment 1 Gyuyoung Kim 2012-08-07 11:27:13 PDT
In WebViewHost class of chromium port, didReceiveResponse() returns "application/octet-stream" when MIME type is empty as below.

void WebViewHost::didReceiveResponse(WebFrame*, unsigned identifier, const WebURLResponse& response)
{
    ...
    if (m_shell->shouldDumpResourceResponseMIMETypes()) {
        GURL url = response.url();
        WebString mimeType = response.mimeType();
        printf("%s has MIME type %s\n",
            url.ExtractFileName().c_str(),
            // Simulate NSURLResponse's mapping of empty/unknown MIME types to application/octet-stream
            mimeType.isEmpty() ? "application/octet-stream" : mimeType.utf8().data());
    }
}

However, in EFL port case, we just print real mime_type, which has text/plain.

void DumpRenderTreeChrome::onResponseReceived(void*, Evas_Object*, void* eventInfo)
{
    ...
    if (!done && gLayoutTestController->dumpResourceResponseMIMETypes()) {
        printf("%s has MIME type %s\n",
               KURL(ParsedURLString, response->url).lastPathComponent().utf8().data(),
               response->mime_type);
    }
}

It looks there is some implementation difference between chromium port and EFL port. Thus, it seems EFL port needs to have new expected result.
Comment 2 Gyuyoung Kim 2012-08-07 11:31:30 PDT
Created attachment 156964 [details]
Patch
Comment 3 Gyuyoung Kim 2012-08-07 11:35:15 PDT
CC'ing Hajime, could you take a look this patch? I'm not sure if EFL port can have new expected result for subresource.html. If default mime type can be changed when mime type is empty in chromium port, I think EFL port doesn't need to have new expected result for subresource.html.
Comment 4 WebKit Review Bot 2012-08-07 16:54:40 PDT
Comment on attachment 156964 [details]
Patch

Clearing flags on attachment: 156964

Committed r124946: <http://trac.webkit.org/changeset/124946>
Comment 5 WebKit Review Bot 2012-08-07 16:54:45 PDT
All reviewed patches have been landed.  Closing bug.