Bug 44282 – [Qt] http/tests/incremental/slow-utf8-text.pl fails

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Ademar Reis]

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.

[Robert Hogan]

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.

[Robert Hogan]

Created attachment 79060 [details]
Patch

[Simon Hausmann]

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 :)

[WebKit Commit Bot]

Comment on attachment 79060 [details]
Patch

Clearing flags on attachment: 79060

Committed r76079: <http://trac.webkit.org/changeset/76079>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.