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
Summary: REGRESSION(r250597): [GTK][WPE] 2.27.1 shows HTML content as text/plain in cu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-07 05:48 PDT by Milan Crha
Modified: 2019-10-09 00:42 PDT (History)
8 users (show)

See Also:


Attachments
Patch (7.97 KB, patch)
2019-10-08 01:41 PDT, Carlos Garcia Campos
zan: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2019-10-07 05:48:45 PDT
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();
Comment 1 Carlos Garcia Campos 2019-10-07 07:09:03 PDT
(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.
Comment 2 Milan Crha 2019-10-07 09:31:21 PDT
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.
Comment 3 Milan Crha 2019-10-08 00:23:06 PDT
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.
Comment 4 Carlos Garcia Campos 2019-10-08 01:36:25 PDT
(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.
Comment 5 Carlos Garcia Campos 2019-10-08 01:41:32 PDT
Created attachment 380413 [details]
Patch
Comment 6 EWS Watchlist 2019-10-08 01:42:03 PDT
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
Comment 7 Milan Crha 2019-10-08 03:50:54 PDT
I tested the patch here (with custom build https://koji.fedoraproject.org/koji/taskinfo?taskID=38139810 ) and I can confirm it fixes the regression.
Comment 8 Milan Crha 2019-10-08 03:53:20 PDT
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.
Comment 9 Carlos Garcia Campos 2019-10-09 00:42:12 PDT
Committed r250899: <https://trac.webkit.org/changeset/250899>