Bug 230797 - REGRESSION(r276635): [SOUP] local HTML file is downloaded instead of displayed if any application has ever called g_desktop_app_info_set_as_default_for_extension(info, "html")
Summary: REGRESSION(r276635): [SOUP] local HTML file is downloaded instead of displaye...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL: https://gitlab.gnome.org/GNOME/glib/-...
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-25 06:57 PDT by Pierre Labastie
Modified: 2022-05-06 12:23 PDT (History)
10 users (show)

See Also:


Attachments
Patch (2.67 KB, patch)
2021-10-19 12:03 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Labastie 2021-09-25 06:57:42 PDT
This does not seem to be a duplicate of https://bugs.webkit.org/show_bug.cgi?id=160347, since it works with webkitgtk-2.32.x, and not with webkitgtk-2.34.0.

My system is a custom one (https://www.linuxfromscratch.org/blfs). shared-mime-info version is 2.1.

Step to reproduce: build from source according to instructions at https://www.linuxfromscratch.org/blfs/view/svn/x/webkitgtk.html

After installation run /usr/libexec/webkit2gtk-4.0/MiniBrowser

enter the url: file:///tmp/index.html

The file /tmp/index.html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content=
    "application/xhtml+xml; charset=iso-8859-1" />
  </head>
  <body>
    <h1>
      Linux From Scratch
    </h1>
  </body>
</html>

with webkitgtk-2.32.4:
Linux From Scratch is displayed
with webkitgkt-2.34.0:
the index.html file is "downloaded" to ~/Downloads

Note that I log the installed files, and I clear them before installing the other version.
Not sure which information you might need. Please ask.
Comment 1 Pierre Labastie 2021-10-10 04:40:54 PDT
I've made some progress on this issue, that is I found how to reproduce it.
It happens if there is a mime directory in $HOME/.local/share, which contains a mime type definition for the html extension. This can be created as follow:

Create the following program (say create-user-html-ext.c):

#include <gio/gio.h>

int main(int argc, char **argv)
{
    GAppInfo *dummy_app_info =
              g_app_info_create_from_commandline ("dummy_app",
                                                  NULL,
                                                  G_APP_INFO_CREATE_NONE,
                                                  NULL);
    g_app_info_set_as_default_for_extension
                               (dummy_app_info,
                                "html",
                                NULL);
}

Compile it:
gcc -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -o create-user-html-ext -lgio-2.0 -lgobject-2.0 -lglib-2.0 create-user-html-ext.c

Run it:
./create-user-html-ext

Run MiniBrowser, and enter the file url as in the initial report

Then you should observe the reported behavior: works with 2.32.4, regression in 2.34.0.

Don't forget to (recursively) remove $HOME/.local/share/mime after the test...

Note that any application can use libgio to create those files more or less automatically, so this bug may be triggered without the user knowing (as happened to me: some application that run in January 2020).
Comment 2 Michael Catanzaro 2021-10-10 05:35:52 PDT
Uhhh. Loads via API request (webkit_web_view_load_uri() etc., like you're doing with your MiniBrowser test) should always load in WebKit. Only actual downloads (download=) should use the default HTML handler. Sounds like a WebKit regression indeed.
Comment 3 Pierre Labastie 2021-10-15 09:46:26 PDT
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.
Comment 4 Michael Catanzaro 2021-10-15 17:40:30 PDT
> 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.
Comment 5 Michael Catanzaro 2021-10-15 17:42:55 PDT
(In reply to Michael Catanzaro from comment #4)
> 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().

Maybe g_desktop_app_info_set_as_default_for_extension() should only create the x-extension-foo MIME type after first checking if xdg_mime_get_mime_type_from_file_name() fails. If it returns something, modify that one instead.
Comment 6 Pierre Labastie 2021-10-16 03:08:40 PDT
FWIIW, if you start firefox for a new user, and you click on "make firefox your default browser" (yeah, I understand that I shouldn't tell this story on a WebKit bug comment :), then the .local/share/mime user database is created using g_app_info_set_as_default_for_extension, at least on GNU-linux (not tested on other OS'es). It defines a mime type for .html, .htm, .shtml, .xhtml, and .xht.

Whether or not firefox expects to find application/x-extension-html as a MIME type, I have not analyzed...

Besides mozilla apps (firefox, thunderbird, seamonkey), other users of g_app_info_set_as_default_for_extension are evolution, evolution-data-server, glibmm, gobject-introspection, pygobject, libfm, libdazzle, librsvg, and vala (among the packages I have built on my system. There are certainly others.)

I have not analyzed what those packages do (although my guess is that glibmm, go-i, pygobjet, and vala just provide wrappers or bindings).
Comment 7 Pierre Labastie 2021-10-16 05:33:30 PDT
(In reply to Pierre Labastie from comment #6)
> FWIIW, if you start firefox for a new user, and you click on "make firefox
> your default browser" (yeah, I understand that I shouldn't tell this story
> on a WebKit bug comment :), then the .local/share/mime user database is
> created using g_app_info_set_as_default_for_extension, at least on GNU-linux
> (not tested on other OS'es). It defines a mime type for .html, .htm, .shtml,
> .xhtml, and .xht.
> 
> Whether or not firefox expects to find application/x-extension-html as a
> MIME type, I have not analyzed...
> 
> Besides mozilla apps (firefox, thunderbird, seamonkey), other users of
> g_app_info_set_as_default_for_extension are evolution,
> evolution-data-server, glibmm, gobject-introspection, pygobject, libfm,
> libdazzle, librsvg, and vala (among the packages I have built on my system.
> There are certainly others.)
> 
> I have not analyzed what those packages do (although my guess is that
> glibmm, go-i, pygobjet, and vala just provide wrappers or bindings).

EDIT:
Actually, not evolution, nor evolution-data-server, nor libfm, (my search string was not long enough); I guess librsvg only defines a rust wrapper but doesn't use it (might be wrong, my rust knowledge is small); and libdazzle seems to reference it only in tests.
Comment 8 Michael Catanzaro 2021-10-19 10:08:49 PDT
This is causing https://gitlab.gnome.org/GNOME/devhelp/-/issues/56.
Comment 9 Michael Catanzaro 2021-10-19 10:11:59 PDT
Oh and the reason I didn't notice: Ephy Tech Preview doesn't have permission to read ~/.local/share/mime. So only system apps will be affected.
Comment 10 Philippe Normand 2021-10-19 10:18:35 PDT
Revert?
Comment 11 Michael Catanzaro 2021-10-19 10:28:20 PDT
Workaround:

$ rm ~/.local/share/mime/packages/user-extension-html.xml
$ update-mime-database ~/.local/share/mime

(In reply to Philippe Normand from comment #10)
> Revert?

Maybe. I'm not sure. We're discussing in #gnome-hackers:gnome.org.

How important was this commit for AVIF? Can you make it work some other way?
Comment 12 Michael Catanzaro 2021-10-19 11:38:46 PDT
(In reply to Philippe Normand from comment #10)
> Revert?

I think we do indeed need to revert, because we are indeed now misdetecting HTML vs. XHTML if the XHTML file uses the .html file extension. Both text/html and application/xhtml+xml register a glob for *.html, exactly the same as this fake application/x-extension-html does. If we rely on filename alone to select the content type, there's no way to choose the right one and we cannot win.

Test case:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content=
    "application/xhtml+xml; charset=iso-8859-1" />
  </head>
  <P>
    This document is not valid XHTML, so you should see a parser error. You should not see this text.
  </p>
</html>

Prior to r276635, that document displayed a parser error because the <P> tag is capitalized, which is not valid XHTML. That was the correct behavior. Since r276635, that document now renders "correctly," which indicates WebKit is treating it as HTML rather than XHTML. That is not correct because it could cause broken rendering of actual XHTML content. (My test case shows the opposite because it's a lot easier. I'm sure you could construct an example XHTML page that previously rendered correctly but no longer does.)

Note that when loaded via HTTP or HTTPS, the content type set by the HTTP header takes precedence, so this is best tested using local files.
Comment 13 Michael Catanzaro 2021-10-19 12:03:57 PDT
Created attachment 441766 [details]
Patch
Comment 14 Michael Catanzaro 2021-10-19 12:05:15 PDT
What really surprises me: r276635 should have broken layout tests. It's unbelievable that we don't have any layout tests that depend on XHTML vs. HTML differences. I wonder if it did break some tests and we just missed the bug report, or if something is funny with the tests.
Comment 15 EWS 2021-10-20 00:54:41 PDT
Committed r284521 (243264@main): <https://commits.webkit.org/243264@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 441766 [details].
Comment 16 Carlos Alberto Lopez Perez 2021-10-21 04:31:01 PDT
(In reply to EWS from comment #15)
> Committed r284521 (243264@main): <https://commits.webkit.org/243264@main>
> 
> All reviewed patches have been landed. Closing bug and clearing flags on
> attachment 441766 [details].

This has caused around ~300 unexpected failures

Run with 284520 -> "failed 13 flakes 42 failures"  <https://build.webkit.org/#/builders/199/builds/2150>
Run with 284521 -> "failed 21 flakes 320 failures" <https://build.webkit.org/#/builders/199/builds/2151>
Comment 17 Michael Catanzaro 2021-10-21 07:02:55 PDT
(In reply to Carlos Alberto Lopez Perez from comment #16)
> This has caused around ~300 unexpected failures

That's probably good! If this didn't affect layout tests, that would indicate a serious problem with the tests.

(In reply to Carlos Alberto Lopez Perez from comment #16)
> Run with 284520 -> "failed 13 flakes 42 failures" 
> <https://build.webkit.org/#/builders/199/builds/2150>
> Run with 284521 -> "failed 21 flakes 320 failures"
> <https://build.webkit.org/#/builders/199/builds/2151>

Any chance these tests were rebaselined after r276635 landed? This was just a revert, so I would expect the test results to go back to what they were prior to r276635. Sadly, I don't see any mention of this in bug #222867.
Comment 18 Lauro Moura 2021-10-21 10:07:38 PDT
(In reply to Michael Catanzaro from comment #17)
> 
> Any chance these tests were rebaselined after r276635 landed? This was just
> a revert, so I would expect the test results to go back to what they were
> prior to r276635. Sadly, I don't see any mention of this in bug #222867.

Checking fast/body-propagation/background-image/003.html, its shared glib baseline was last touched last year, right when we merged the gtk/wpe ones.

Sample diff from fast/body-propagation/background-image/003.html:

--- /home/lauro/dev/WebKit/layout-test-results/fast/body-propagation/background-image/003-expected.txt
+++ /home/lauro/dev/WebKit/layout-test-results/fast/body-propagation/background-image/003-actual.txt
@@ -2,7 +2,7 @@
   RenderView at (0,0) size 800x600
 layer at (0,0) size 800x34
   RenderBlock {html} at (0,0) size 800x34
-    RenderBody {BODY} at (8,8) size 784x18
-      RenderBlock {P} at (0,0) size 784x18
+    RenderBody {body} at (8,8) size 784x18
+      RenderBlock {p} at (0,0) size 784x18
         RenderText {#text} at (0,0) size 334x17
           text run at (0,0) width 334: "This line should be green and there should be no red."

It seems the `document().isHTMLDocument()` is returning false inside  `HTMLElement::nodeName()` (used when dumping the render tree). Maybe some other commit also affected this check and reverting r276635 just uncovered the issue.
Comment 19 Michael Catanzaro 2021-10-21 12:42:48 PDT
(In reply to Lauro Moura from comment #18)
> ---
> /home/lauro/dev/WebKit/layout-test-results/fast/body-propagation/background-
> image/003-expected.txt
> +++
> /home/lauro/dev/WebKit/layout-test-results/fast/body-propagation/background-
> image/003-actual.txt
> @@ -2,7 +2,7 @@
>    RenderView at (0,0) size 800x600
>  layer at (0,0) size 800x34
>    RenderBlock {html} at (0,0) size 800x34
> -    RenderBody {BODY} at (8,8) size 784x18
> -      RenderBlock {P} at (0,0) size 784x18
> +    RenderBody {body} at (8,8) size 784x18
> +      RenderBlock {p} at (0,0) size 784x18
>          RenderText {#text} at (0,0) size 334x17
>            text run at (0,0) width 334: "This line should be green and there
> should be no red."

The uppercase tags are valid HTML, but not valid XHTML. So I think this diff indicates that WebKit was previously processing the file as HTML, but is now processing it as XHTML.

(In reply to Lauro Moura from comment #18)
> It seems the `document().isHTMLDocument()` is returning false inside 
> `HTMLElement::nodeName()` (used when dumping the render tree). Maybe some
> other commit also affected this check and reverting r276635 just uncovered
> the issue.

Seems reasonable, because the test file is malformed:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

The first line declares that it is HTML, then the second line indicates XHTML. The content sniffing is probably picking up xmlns and xhtml in the second line and giving precedence to those.

Of course, it would be *better* for WebKit to make content type decisions based on the DOCTYPE instead, but we can't expect a content sniffer to do that. We would have to implement it ourselves in WebKit, rather than farming out the work to GIO. I wonder how other ports handle this.

(In reply to Carlos Alberto Lopez Perez from comment #16)
> This has caused around ~300 unexpected failures

I'm not certain what we should do with these.
Comment 20 Michael Catanzaro 2021-10-21 12:45:35 PDT
Interestingly, there is also fast/body-propagation/background-image/003-html.xhtml, which has the exact same content:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

The only difference is the file extension....
Comment 21 Arcady Goldmints-Orlov 2021-10-27 09:48:12 PDT
I've rebaselined most of the tests that just had different capitalization of the tags in the render tree, but there are still a lot of tests that just report a parse error, presumably because the file is being interpreted as XHTML and the parse fails as a result. I suppose I can open a separate bug for all of those.
Comment 22 Alberto Garcia 2022-04-20 01:47:36 PDT
Not sure if this is the right bug, but I'm still having problems with the parsing of local HTML files.

With WebKitGTK 2.36.0, using the MiniBrowser to open file:///tmp/page.html with these contents:

   <!DOCTYPE html>
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
   <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
   </head>
   <body>
   Hello, world
   </body>
   </html>

This fails with "error on line 5 at column 8: Opening and ending tag mismatch: meta line 0 and head" (because the <meta> tag is not properly closed).

Adding a 'style' attribute to the <html> tag solves the problem:

   <html style="" xmlns="http://www.w3.org/1999/xhtml">

However if I change the order of the attributes and put 'xmlns' first then it fails again:

   <html xmlns="http://www.w3.org/1999/xhtml" style="">
Comment 23 Michael Catanzaro 2022-04-20 05:24:31 PDT
(In reply to Alberto Garcia from comment #22)
> Not sure if this is the right bug, but I'm still having problems with the
> parsing of local HTML files.

I think this regressed again... somehow. Not sure when.
Comment 24 Pierre Labastie 2022-04-20 06:49:27 PDT
(In reply to Alberto Garcia from comment #22)
> Not sure if this is the right bug, but I'm still having problems with the
> parsing of local HTML files.
> 
> With WebKitGTK 2.36.0, using the MiniBrowser to open file:///tmp/page.html
> with these contents:
> 
>    <!DOCTYPE html>
>    <html xmlns="http://www.w3.org/1999/xhtml">
>    <head>
>    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
>    </head>
>    <body>
>    Hello, world
>    </body>
>    </html>
> 
> This fails with "error on line 5 at column 8: Opening and ending tag
> mismatch: meta line 0 and head" (because the <meta> tag is not properly
> closed).

Your meta tag lacks a trailing slash: should be
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>

> 
> Adding a 'style' attribute to the <html> tag solves the problem:
> 
>    <html style="" xmlns="http://www.w3.org/1999/xhtml">

Amazing: the XML is still malformed, so should return the same output as above...

> 
> However if I change the order of the attributes and put 'xmlns' first then
> it fails again:
> 
>    <html xmlns="http://www.w3.org/1999/xhtml" style="">
Comment 25 Pierre Labastie 2022-04-20 07:00:30 PDT
(In reply to Michael Catanzaro from comment #23)
> (In reply to Alberto Garcia from comment #22)
> > Not sure if this is the right bug, but I'm still having problems with the
> > parsing of local HTML files.
> 
> I think this regressed again... somehow. Not sure when.

Definitely regressed: webkit-2.36.0: evolution wants again to "download" file:/// urls (actually copy the file to ~/Downloads, then ask whether the user wants to "open" it, then display it with ... firefox :). And so does MiniBrowser. I still have some content in ~/.local/share/mime, so maybe this is the "reason". but webkit-2.34.x (x=1,3,5,6 at least) series was showing the correct behavior with the same .local directory...
Comment 26 Pierre Labastie 2022-04-20 07:02:31 PDT
(In reply to Pierre Labastie from comment #25)
> (In reply to Michael Catanzaro from comment #23)
> > (In reply to Alberto Garcia from comment #22)
> > > Not sure if this is the right bug, but I'm still having problems with the
> > > parsing of local HTML files.
> > 
> > I think this regressed again... somehow. Not sure when.
> 
> Definitely regressed: webkit-2.36.0: evolution wants again to "download"
> file:/// urls (actually copy the file to ~/Downloads, then ask whether the
> user wants to "open" it, then display it with ... firefox :). And so does
> MiniBrowser. I still have some content in ~/.local/share/mime, so maybe this
> is the "reason". but webkit-2.34.x (x=1,3,5,6 at least) series was showing
> the correct behavior with the same .local directory...

Removing ~/.local/share/mime allows to display file:/// urls
Comment 27 Pierre Labastie 2022-04-20 07:05:10 PDT
Reopening since the issue seems very similar.
Comment 28 Alberto Garcia 2022-04-20 07:06:55 PDT
(In reply to Pierre Labastie from comment #24)
> Your meta tag lacks a trailing slash: should be
> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>

I know, and this is on purpose because this example is based on actual
HTML pages that people are using on a daily basis and that every other
browser can open just fine.
Comment 29 Alberto Garcia 2022-04-20 07:09:41 PDT
(In reply to Pierre Labastie from comment #26)
> Removing ~/.local/share/mime allows to display file:/// urls

I don't have ~/.local/share/mime and I still get that error.

On a Debian system I can reproduce the problem by simply doing this:

$ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser file:///tmp/hello.html
Comment 30 Pierre Labastie 2022-04-20 07:47:38 PDT
(In reply to Alberto Garcia from comment #28)
> (In reply to Pierre Labastie from comment #24)
> > Your meta tag lacks a trailing slash: should be
> > <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
> 
> I know, and this is on purpose because this example is based on actual
> HTML pages that people are using on a daily basis and that every other
> browser can open just fine.

Ok so maybe not really the same issue, but could be related... FWIIW, and as I said in a previous comment, the (well formed) index.html given in the initial report can be opened when there is nothing in ~/.local/share/mime.
Comment 31 Pierre Labastie 2022-04-20 07:50:32 PDT
(In reply to Pierre Labastie from comment #25)
> (In reply to Michael Catanzaro from comment #23)
> > (In reply to Alberto Garcia from comment #22)
> > > Not sure if this is the right bug, but I'm still having problems with the
> > > parsing of local HTML files.
> > 
> > I think this regressed again... somehow. Not sure when.
> 
> Definitely regressed: webkit-2.36.0: evolution wants again to "download"
> file:/// urls (actually copy the file to ~/Downloads, then ask whether the
> user wants to "open" it, then display it with ... firefox :). And so does
> MiniBrowser. I still have some content in ~/.local/share/mime, so maybe this
> is the "reason". but webkit-2.34.x (x=1,3,5,6 at least) series was showing
> the correct behavior with the same .local directory...

Edit: obviously, this is not "evolution", but "epiphany/web", sorry...
Comment 32 Michael Catanzaro 2022-04-20 08:22:48 PDT
(In reply to Alberto Garcia from comment #29)
> I don't have ~/.local/share/mime and I still get that error.

Please report a new bug, then. What you're hitting is probably *caused* by the fix for this bug. To fix the regression here, I needed to restore content sniffing. Your new example is surely a case where the content sniffing fails.

If you right click on your hello.html in nautilus, and look at the file's Type, what does it say? I see "XHTML page (application/xhtml+xml)". MiniBrowser attempts to display it and fails because it's not valid XHTML, but does not attempt to download it. I expect that for you it's going to show some MIME type that we cannot display. (I have shared-mime-info 2.1.)
Comment 33 Pierre Labastie 2022-04-20 09:58:30 PDT
I do have an issue when ~/.local/share/mime is populated by firefox. Here is a way to get the bug:
If you have firefox, and firefox is not your default browser:
open firefox
go to about:preferences
in general, click "make firefox your default browser"

Then a mime directory is installed into .local/share and nautilus tells the mime time of /tmp/index.html is:
html document (application/x-extension-html)

So I think this should get reopened: leaving this up to you. If you prefer, I can make a new bug for webkitgtk-2.36, but it seems to be really the same bug.

I agree the one reported in comment #22 is not the same...
Comment 34 Michael Catanzaro 2022-04-20 12:14:31 PDT
That is https://gitlab.gnome.org/GNOME/glib/-/issues/2511, which is not fixed. That shouldn't cause WebKit to download files anymore after https://commits.webkit.org/243264@main.

If you revert https://commits.webkit.org/243264@main, then you'll (probably) fix the case that Berto is complaining about now in comment #22, but you'll reintroduce the original bug here... and *then* we would want to reopen this.
Comment 35 Pierre Labastie 2022-04-20 14:40:59 PDT
(In reply to Michael Catanzaro from comment #34)
> That is https://gitlab.gnome.org/GNOME/glib/-/issues/2511, which is not
> fixed. That shouldn't cause WebKit to download files anymore after
> https://commits.webkit.org/243264@main.

My point is that it does cause WebKit to download files in webkitgtk-2.36.0, although https://commits.webkit.org/243264@main is applied there (I just checked). It's a regression respective to the 2.34.x series (x>0). The original report was for 2.34.0, and has been fixed by the above commit. But for 2.36.0, something else seems to have reintroduced the bug...

> 
> If you revert https://commits.webkit.org/243264@main, then you'll (probably)
> fix the case that Berto is complaining about now in comment #22, but you'll
> reintroduce the original bug here... and *then* we would want to reopen this.

I'm sorry if I sounded like this bug should be reopened because of comment #22. It is another issue, which is similar to the original bug.
Comment 36 Michael Catanzaro 2022-04-21 06:10:20 PDT
Are you sure you're experiencing the same bug with the same files as before? And downgrading 2.36 -> 2.34 is sufficient to fix the issue? Then it is possible for you to bisect it and find out what commit broke it (if you're sufficiently patient).

I'm skeptical because Berto is describing a confusingly-similar yet clearly distinct problem. He has opened bug #239597 for this.
Comment 37 Pierre Labastie 2022-04-21 09:08:30 PDT
(In reply to Michael Catanzaro from comment #36)
> Are you sure you're experiencing the same bug with the same files as before?
> And downgrading 2.36 -> 2.34 is sufficient to fix the issue? Then it is
> possible for you to bisect it and find out what commit broke it (if you're
> sufficiently patient).
> 
> I'm skeptical because Berto is describing a confusingly-similar yet clearly
> distinct problem. He has opened bug #239597 for this.

The answer to the first question is yes: same files as before, using MiniBrowser, file:///tmp/index.html is downloaded if .local/share/mime has been populated by g_desktop_app_info_set_as_default_for_extension. But to my amazement, downgrading to 2.34 did not solve the bug. The problem is glib-2.72: downgrading to glib-2.70 is enough to have the file displayed, even with webkitgtk-2.36. Sorry for the noise. I'm bisecting glib right now, but they have a bunch of commits that FTBFS, so it takes a little more time...

Will open an issue in glib once I find something (and report here).
Comment 38 Pierre Labastie 2022-04-21 13:30:13 PDT
You might be interested in the glib commits that reintroduce the bug (most recent first):
fa6f45536 xdgmime: Add xdg_mime_set_dirs() method to override XDG envvars
b765c7950 gio/xdgmime/: LGPLv2+ -> LGPLv2.1+
e4d181336 xdgmime: Finer handling for cases where mmap() is not available
e7822bd30 Silence an uninitialize variable warning
14e46ca28 Don't compile some unused functions in gio/xdgmime/
a1bfe899a Don't give up too early when collecting mime types
b4893986b Force to use the config.h header file (required for HAVE_MMAP macro)
3d2ac608d Update gio/xdgmime with commit 722325f of xdgmime project

Note that all those commits except fa6f45536 lack xdg_mime_set_dirs so cannot be built.

I'm not sure how to report the issue to glib...
Comment 39 Michael Catanzaro 2022-04-21 13:42:24 PDT
Ah, well it broke in 3d2ac608d then.

Might as well track this here for now, since it's as yet unclear whether anything is wrong in GLib.
Comment 40 Michael Catanzaro 2022-05-05 09:36:11 PDT
Another glib issue: https://gitlab.gnome.org/GNOME/glib/-/issues/2639
Comment 41 Michael Catanzaro 2022-05-06 12:23:15 PDT
Let's track this problem in bug #238347, since the original issue here is solved, and it's not our regression.