[Webkit-unassigned] [Bug 230797] REGRESSION(r276635): [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 #4 from Michael Catanzaro <mcatanzaro at gnome.org> ---
> 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.

----

Thinking about GLib:

Well that sucks. So g_desktop_app_info_set_as_default_for_extension() is sabotage if it's ever used for any extension that corresponds to a MIME type in the system database. I'll probably need to forward this to the GLib issue tracker to decide what to do but I expect we're going to need to rewrite g_desktop_app_info_set_as_default_for_extension().

----

Thinking about WebKit:

Ironically, r276635 was intended to make MIME type detection *more* robust by assuming the file extension accurately indicates MIME type if we have an exact match, instead of passing the file contents to shared-mime-info and allowing it to sometimes guess wrong. What went wrong here is you have an exact match for "*.html" that is bogus and overrides the real application/html. I was going to say "I don't think we should revert it, because avoiding shared-mime-info if possible should help avoid mistakes," but... actually, maybe we need to, because your test file is *NOT* HTML at all! It is XHTML, which is different. I would expect WebKit would screw up rendering if it tries loading XHTML as HTML or vice-versa, but if it tries MIMETypeRegistry::mimeTypeForExtension first it's going to get it wrong (because XHTML often uses the normal .html extension). Your test case looks sufficiently simple that it didn't trip over any of the differences between HTML and XHTML.

-- 
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/20211016/03e33a24/attachment-0001.htm>