[Webkit-unassigned] [Bug 202321] [GTK] Web Inspector: page error with shared-mime-info 1.14

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 16 03:58:00 PDT 2019


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

--- Comment #19 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Michael Catanzaro from comment #16)
> (In reply to Bastien Nocera from comment #15)
> > I'll repeat it once more though, WebKitGTK seriously needs to stop using
> > shared-mime-info to detect whether files are one type or the other. Or
> > somebody needs to take all the internal html pages and add them to the
> > shared-mime-info test suite so it doesn't regress.
> 
> I'll just add: Bastien has recommended this many times, and so has Alexey,
> most recently in bug #201545.
> 
> It would require removing the SoupContentSniffer feature. Note that feature
> might be added by default now (check the SoupSession documentation), so just
> removing it from the SoupSession initialization isn't enough because that is
> probably redundant. It should be explicitly removed.

long history; short:

1. Someone assigns ".html" and ".htm" to XML type in shared-mime-info because:

"So that WebKitGTK+ can detect mime-types more reliably for local
XHTML files which wouldn't be detected as XHTML through magic."

https://cgit.freedesktop.org/xdg/shared-mime-info/commit/freedesktop.org.xml.in?id=8ae13a589577e9bda12fb16465a03cd81b1cd349


2. We decide that shared-mime-info is broken because of that and stop using it?


What's the point of 1. then? What does it "fixes" if we stop relying on shared-mime-info? Shouldn't 1. just be reverted on shared-mime-info instead?

I think that 1. was a bad idea from the beginning. If the file ends in ".htm" or ".html" but is an XML it should be just renamed to ".xhtml" or something instead of having shared-mime-info guessing it by the contents.

-- 
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/20191016/aefd3eab/attachment-0001.html>


More information about the webkit-unassigned mailing list