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

[bugzilla-daemon at webkit.org]

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

--- Comment #21 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Bastien Nocera from comment #20)
> (In reply to Carlos Alberto Lopez Perez from comment #19)
> > (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.
> 
> shared-mime-info doesn't "detect" anything. It's a database, which
> applications can use how they see fit. Some of them will use pass a filename
> to an API that consumes the database, others will pass data, some will pass
> both.
> 

Well, the reality is that a file that ends in ".html" gets identified as XML since the mentioned commit in shared-mime-info. Not sure how a discussion about if shared-mime-info is a database, an API or a program helps here.


> Furthermore, shared-mime-info is built for end-users, not for programmers,
> which aren't really supposed to know whether a webpage is HTML or XHTML.
> shared-mime-info test suite needs to be fed some of the data that WebKitGTK
> relies on to function properly.

That's news to me. How I'm supposed as end-user to use shared-mime-info? On my debian system the only program shared-mime-info includes is update-mime-database.

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