[Webkit-unassigned] [Bug 230797] REGRESSION(r276635): [GTK] local HTML file is downloaded instead of displayed if any application has ever called g_desktop_app_info_set_as_default_for_extension(info, "html")

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 19 11:38:46 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=230797

--- Comment #12 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Philippe Normand from comment #10)
> Revert?

I think we do indeed need to revert, because we are indeed now misdetecting HTML vs. XHTML if the XHTML file uses the .html file extension. Both text/html and application/xhtml+xml register a glob for *.html, exactly the same as this fake application/x-extension-html does. If we rely on filename alone to select the content type, there's no way to choose the right one and we cannot win.

Test case:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content=
    "application/xhtml+xml; charset=iso-8859-1" />
  </head>
  <P>
    This document is not valid XHTML, so you should see a parser error. You should not see this text.
  </p>
</html>

Prior to r276635, that document displayed a parser error because the <P> tag is capitalized, which is not valid XHTML. That was the correct behavior. Since r276635, that document now renders "correctly," which indicates WebKit is treating it as HTML rather than XHTML. That is not correct because it could cause broken rendering of actual XHTML content. (My test case shows the opposite because it's a lot easier. I'm sure you could construct an example XHTML page that previously rendered correctly but no longer does.)

Note that when loaded via HTTP or HTTPS, the content type set by the HTTP header takes precedence, so this is best tested using local files.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211019/39cc1b7d/attachment-0001.htm>


More information about the webkit-unassigned mailing list