[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