Full Text Bug Listing

Pierre Labastie

Reported 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.

Pierre Labastie

Comment 1 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).

Michael Catanzaro

Comment 2 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.

Pierre Labastie

Comment 3 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.

Michael Catanzaro

Comment 4 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.

Michael Catanzaro

Comment 5 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.

Pierre Labastie

Comment 6 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).

Pierre Labastie

Comment 7 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.

Michael Catanzaro

Comment 8 2021-10-19 10:08:49 PDT

This is causing https://gitlab.gnome.org/GNOME/devhelp/-/issues/56.

Michael Catanzaro

Comment 9 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.

Philippe Normand

Comment 10 2021-10-19 10:18:35 PDT

Revert?

Michael Catanzaro

Comment 11 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?

Michael Catanzaro

Comment 12 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.

Michael Catanzaro

Comment 13 2021-10-19 12:03:57 PDT

Created attachment 441766 [details] Patch

Michael Catanzaro

Comment 14 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.

EWS

Comment 15 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].

Carlos Alberto Lopez Perez

Comment 16 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>

Michael Catanzaro

Comment 17 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.

Lauro Moura

Comment 18 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.

Michael Catanzaro

Comment 19 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.

Michael Catanzaro

Comment 20 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....

Arcady Goldmints-Orlov

Comment 21 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.

Alberto Garcia

Comment 22 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="">

Michael Catanzaro

Comment 23 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.

Pierre Labastie

Comment 24 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="">

Pierre Labastie

Comment 25 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...

Pierre Labastie

Comment 26 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

Pierre Labastie

Comment 27 2022-04-20 07:05:10 PDT

Reopening since the issue seems very similar.

Alberto Garcia

Comment 28 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.

Alberto Garcia

Comment 29 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

Pierre Labastie

Comment 30 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.

Pierre Labastie

Comment 31 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...

Michael Catanzaro

Comment 32 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.)

Pierre Labastie

Comment 33 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...

Michael Catanzaro

Comment 34 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.

Pierre Labastie

Comment 35 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.

Michael Catanzaro

Comment 36 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.

Pierre Labastie

Comment 37 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).

Pierre Labastie

Comment 38 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...

Michael Catanzaro

Comment 39 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.

Michael Catanzaro

Comment 40 2022-05-05 09:36:11 PDT

Another glib issue: https://gitlab.gnome.org/GNOME/glib/-/issues/2639

Michael Catanzaro

Comment 41 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.

Attachments
Patch (2.67 KB, patch) 2021-10-19 12:03 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Bug 230797