[Webkit-unassigned] [Bug 230797] [GTK] 2.34: local html file is downloaded instead of displayed. Works ok for webkitgtk-2.32.4

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Pierre Labastie <pierre.labastie at neuf.fr> ---
I've found the commit that triggered the change in behavior between 2.32 and 2.34: it is commit 5f694471d0d885bd292960af132ee9334474ab45, or r276635 for svn.

That commit inverted the logic for mime type detection, going from:
1. try extractMIMETypeFromMediaType
2. then try mimeTypeForPath

to the reverse. Problem is that mimeTypeForPath uses mimeTypeForExtension, and I guess the GTK port uses the one in MIMETypeRegistryXdg.cpp, which itself uses
xdg_mime_get_mime_type_from_file_name from xdgmime.c. This ones first tries the user mime database (in $XDG_DATA_HOME/mime (default .local/share/mime), then the system database (from XDG_DATA_DIRS path, adding mime). If there is something in the user database, this is what is returned. If the user database is created by gio, the mime type is application/x-extension-html, which is not in the WebKit mime type registry, so that the file is not recognized as html. With shared-mime-info-2.1, the system database returns application/xhtml+xml (which it should), and that is recognized as html in the WebKit registry .

I do not know what extractMIMETypeFromMediaType returns, but it is recognized as html too, so all is well if that one is used.

For my use case (I do not tell it is what you should do), I've reverted the order of the checks in etworkProcess/soup/NetworkDataTaskSoup.cpp, and the file:///xxx.html is displayed as it should.

-- 
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/20211015/70897bb1/attachment.htm>