Implement layoutTestController.dumpResourceResponseMIMETypes in test_shell...

Implement layoutTestController.dumpResourceResponseMIMETypes in test_shell
(Chromium DRT side of this is in http://webkit.org/b/45479).

BUG=46872
TEST=fast/preloader and other layout tests now pass

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=58994

[tony, 2010-09-09 18:36:29]

LGTM, just a small nit

http://codereview.chromium.org/3317016/diff/1/5
File webkit/tools/test_shell/test_webview_delegate.cc (right):

http://codereview.chromium.org/3317016/diff/1/5#newcode1062
webkit/tools/test_shell/test_webview_delegate.cc:1062:
"application/octet-stream" : mimeType.utf8().data());
Is mimeType.utf8().data() null terminated (looking in
JavaScriptCore/wtf/text/CString.h, it doesn't look like it)?   Should we convert
to std::string and use c_str() instead?

[Mihai Parparita -not on Chrome, 2010-09-09 19:26:22]

On 2010/09/09 18:36:29, tony wrote:
> http://codereview.chromium.org/3317016/diff/1/5#newcode1062
> webkit/tools/test_shell/test_webview_delegate.cc:1062:
> "application/octet-stream" : mimeType.utf8().data());
> Is mimeType.utf8().data() null terminated (looking in
> JavaScriptCore/wtf/text/CString.h, it doesn't look like it)?   Should we
convert
> to std::string and use c_str() instead?

The utf8().data() pattern shows up elsewhere in the file too, and so it seemed
safe. From looking at CString::init, it always null-terminates m_buffer based on
the length (and data() just returns the contents of the data).