Bug 202633 – REGRESSION(r250597): [GTK][WPE] 2.27.1 shows HTML content as text/plain in custom protocols when passing a charset in content type

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Milan Crha]

Evolution talking to webkit2gtk3 2.27.1 shows its iframe content (text/html) as text/plain, effectively showing the HTML code, instead of rendered content. Downgrading to 2.26.1 fixes the problem, thus it's a regression (or a new feature/behaviour?) of WebKitGTK+ itself.

Other things noticed:
a) the evolution console contains two new messages (the below shown twice) with no clear origin:
> Received data during response processing, queuing it.

b) trying to show WebKit inspector opens a page, which contains an error:

   This page contains the following errors:

   error on line 43 at column 8: Opening and ending tag mismatch: link line 0 and head
   Below is a rendering of the page up to the first error.

   WI.sharedApp = new WI.AppController; WI.sharedApp.initialize();

[Carlos Garcia Campos]

(In reply to Milan Crha from comment #0)
> Evolution talking to webkit2gtk3 2.27.1 shows its iframe content (text/html)
> as text/plain, effectively showing the HTML code, instead of rendered
> content. Downgrading to 2.26.1 fixes the problem, thus it's a regression (or
> a new feature/behaviour?) of WebKitGTK+ itself.
> 
> Other things noticed:
> a) the evolution console contains two new messages (the below shown twice)
> with no clear origin:
> > Received data during response processing, queuing it.

This is harmless, but annoying, message shown by the new custom protocols implementation. I think it should be moved as internal log or just removed.

> b) trying to show WebKit inspector opens a page, which contains an error:
> 
>    This page contains the following errors:
> 
>    error on line 43 at column 8: Opening and ending tag mismatch: link line
> 0 and head
>    Below is a rendering of the page up to the first error.
> 
>    WI.sharedApp = new WI.AppController; WI.sharedApp.initialize();

This is bug #202321, I think.

[Milan Crha]

Those are just the other things I noticed. What about the main thing, showing HTML content as raw HTML code, not parsed? That feels like a regression.

[Milan Crha]

This happens when webkit_uri_scheme_request_finish() is called with mime-type

   text/html; charset="UTF-8"

Using the mime-type:

   text/html

doesn't suffer of this issue.

Should the webkit_uri_scheme_request_finish() be called always with a simple mime type, without additional arguments (like those used in Content-Type header)?

This wasn't the case in the past, but I also do not say that Evolution does this correctly. It can be some misunderstanding on the Evolution side.

[Carlos Garcia Campos]

(In reply to Milan Crha from comment #3)
> This happens when webkit_uri_scheme_request_finish() is called with mime-type
> 
>    text/html; charset="UTF-8"
> 
> Using the mime-type:
> 
>    text/html
> 
> doesn't suffer of this issue.
> 
> Should the webkit_uri_scheme_request_finish() be called always with a simple
> mime type, without additional arguments (like those used in Content-Type
> header)?
> 
> This wasn't the case in the past, but I also do not say that Evolution does
> this correctly. It can be some misunderstanding on the Evolution side.

Good catch. This is a regression of the switch to use the new custom protocols implementation. Before r250597, we extracted the mime type and charset from content type in the network process, but we are now sending the response directly from the UI process, so we need to do that when building our response.

[Carlos Garcia Campos]

Created attachment 380413 [details]
Patch

[EWS Watchlist]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Milan Crha]

I tested the patch here (with custom build https://koji.fedoraproject.org/koji/taskinfo?taskID=38139810 ) and I can confirm it fixes the regression.

[Milan Crha]

Just a note, it's not only about charset being passed, the Content-Type variant can contain any custom arguments. If I understood your patch properly, it doesn't matter, but I'm mentioning it here anyway.

[Carlos Garcia Campos]

Committed r250899: <https://trac.webkit.org/changeset/250899>