|Summary:||[Qt] http/tests/incremental/slow-utf8-text.pl fails|
|Product:||WebKit||Reporter:||Ademar Reis <ademar>|
|Component:||Tools / Tests||Assignee:||Robert Hogan <robert>|
|Severity:||Normal||CC:||commit-queue, kenneth, robert, tonikitoo|
|Version:||528+ (Nightly build)|
Description Ademar Reis 2010-08-19 12:06:36 PDT
With current trunk (65688), all http/tests/incremental tests pass with the exception of slow-utf8-text.pl. (a patch enabling them is on the way) I traced the reason for the failure as the inability of our DRT to detect the content-type of the network reply which originated the main frame and dump it as text whenever it's text/plain. In other words, the tests requires the output to be rendered as text but our DRT is rendering it as a tree. I couldn't find a way to retrieve the content-type (MIME) of a QWebFrame. Other ports (gtk/mac) appear to expose public APIs which allow access to WebCore::DocumentLoader::responseMIMEType(), but that's not the case of Qt. Should we have an API for this, add some hack to allow this test to pass, or keep it ignored? Maybe I'm missing something? Given enough directions I could work on this.
Comment 1 Robert Hogan 2010-10-10 03:58:16 PDT
This sounds like a job for DumpRenderTreeSupportQt. We use that for exposing WebCore elements in DRT testing that don't otherwise have an API use case.
Comment 3 Simon Hausmann 2011-01-16 23:53:24 PST
Comment on attachment 79060 [details] Patch I wouldn't mind a function like QString QWebFrame::contentType() const, but your patch certainly does the trick, too :)
Comment 4 WebKit Commit Bot 2011-01-18 15:50:07 PST
Comment on attachment 79060 [details] Patch Clearing flags on attachment: 79060 Committed r76079: <http://trac.webkit.org/changeset/76079>
Comment 5 WebKit Commit Bot 2011-01-18 15:50:16 PST
All reviewed patches have been landed. Closing bug.