230797 2021-09-25 06:57:42 -0700 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") 2022-05-06 12:23:15 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Local Build PC Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=232386 https://bugs.webkit.org/show_bug.cgi?id=239597 https://gitlab.gnome.org/GNOME/glib/-/issues/2511 P2 Normal --- 1 pierre.labastie mcatanzaro berto bugs-noreply cgarcia clopez crzwdjk jtojnar lmoura mcatanzaro pnormand xry111 oldest_to_newest 1797206 0 pierre.labastie 2021-09-25 06:57:42 -0700 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. 1802450 1 pierre.labastie 2021-10-10 04:40:54 -0700 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). 1802451 2 mcatanzaro 2021-10-10 05:35:52 -0700 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. 1804856 3 pierre.labastie 2021-10-15 09:46:26 -0700 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. 1805156 4 mcatanzaro 2021-10-15 17:40:30 -0700 > 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. 1805159 5 mcatanzaro 2021-10-15 17:42:55 -0700 (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. 1805242 6 pierre.labastie 2021-10-16 03:08:40 -0700 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). 1805251 7 pierre.labastie 2021-10-16 05:33:30 -0700 (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. 1806112 8 mcatanzaro 2021-10-19 10:08:49 -0700 This is causing https://gitlab.gnome.org/GNOME/devhelp/-/issues/56. 1806117 9 mcatanzaro 2021-10-19 10:11:59 -0700 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. 1806125 10 pnormand 2021-10-19 10:18:35 -0700 Revert? 1806133 11 mcatanzaro 2021-10-19 10:28:20 -0700 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? 1806195 12 mcatanzaro 2021-10-19 11:38:46 -0700 (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. 1806211 13 441766 mcatanzaro 2021-10-19 12:03:57 -0700 Created attachment 441766 Patch 1806212 14 mcatanzaro 2021-10-19 12:05:15 -0700 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. 1806529 15 ews-feeder 2021-10-20 00:54:41 -0700 Committed r284521 (243264@main): <https://commits.webkit.org/243264@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 441766. 1807082 16 clopez 2021-10-21 04:31:01 -0700 (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> 1807120 17 mcatanzaro 2021-10-21 07:02:55 -0700 (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. 1807227 18 lmoura 2021-10-21 10:07:38 -0700 (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. 1807312 19 mcatanzaro 2021-10-21 12:42:48 -0700 (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. 1807315 20 mcatanzaro 2021-10-21 12:45:35 -0700 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.... 1809285 21 crzwdjk 2021-10-27 09:48:12 -0700 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. 1862858 22 berto 2022-04-20 01:47:36 -0700 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=""> 1862898 23 mcatanzaro 2022-04-20 05:24:31 -0700 (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. 1862920 24 pierre.labastie 2022-04-20 06:49:27 -0700 (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=""> 1862921 25 pierre.labastie 2022-04-20 07:00:30 -0700 (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... 1862922 26 pierre.labastie 2022-04-20 07:02:31 -0700 (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 1862924 27 pierre.labastie 2022-04-20 07:05:10 -0700 Reopening since the issue seems very similar. 1862925 28 berto 2022-04-20 07:06:55 -0700 (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. 1862926 29 berto 2022-04-20 07:09:41 -0700 (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 1862935 30 pierre.labastie 2022-04-20 07:47:38 -0700 (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. 1862936 31 pierre.labastie 2022-04-20 07:50:32 -0700 (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... 1862940 32 mcatanzaro 2022-04-20 08:22:48 -0700 (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.) 1862968 33 pierre.labastie 2022-04-20 09:58:30 -0700 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... 1863018 34 mcatanzaro 2022-04-20 12:14:31 -0700 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. 1863068 35 pierre.labastie 2022-04-20 14:40:59 -0700 (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. 1863269 36 mcatanzaro 2022-04-21 06:10:20 -0700 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. 1863312 37 pierre.labastie 2022-04-21 09:08:30 -0700 (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). 1863382 38 pierre.labastie 2022-04-21 13:30:13 -0700 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... 1863392 39 mcatanzaro 2022-04-21 13:42:24 -0700 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. 1866887 40 mcatanzaro 2022-05-05 09:36:11 -0700 Another glib issue: https://gitlab.gnome.org/GNOME/glib/-/issues/2639 1867303 41 mcatanzaro 2022-05-06 12:23:15 -0700 Let's track this problem in bug #238347, since the original issue here is solved, and it's not our regression. 441766 2021-10-19 12:03:57 -0700 2021-10-20 00:54:43 -0700 Patch bug-230797-20211019140356.patch text/plain 2732 mcatanzaro U3VidmVyc2lvbiBSZXZpc2lvbjogMjg0MjcxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGJjMjRhODdlN2Y0OTllOTQx YzQzYTEyOTVmNDE4Yjg4NThkZGRlMDQuLjMzODJjNzViNzI3YzY2N2IyYjEzZjhmN2RiOTNmMGIx YjRmYjk4YTkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMjEtMTAtMTkgIE1pY2hhZWwg Q2F0YW56YXJvICA8bWNhdGFuemFyb0Bnbm9tZS5vcmc+CisKKyAgICAgICAgUkVHUkVTU0lPTihy Mjc2NjM1KTogW0dUS10gbG9jYWwgSFRNTCBmaWxlIGlzIGRvd25sb2FkZWQgaW5zdGVhZCBvZiBk aXNwbGF5ZWQgaWYgYW55IGFwcGxpY2F0aW9uIGhhcyBldmVyIGNhbGxlZCBnX2Rlc2t0b3BfYXBw X2luZm9fc2V0X2FzX2RlZmF1bHRfZm9yX2V4dGVuc2lvbihpbmZvLCAiaHRtbCIpCisgICAgICAg IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yMzA3OTcKKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBMZXQncyByZXZlcnQgdGhp cyBjaGFuZ2UuIERpc2FibGluZyBjb250ZW50IHNuaWZmaW5nIHByZXZlbnRzIFdlYktpdCBmcm9t IGRpc3Rpbmd1aXNoaW5nCisgICAgICAgIGJldHdlZW4gZGlmZmVyZW50IGNvbnRlbnQgdHlwZXMg d2l0aCB0aGUgc2FtZSBmaWxlIGV4dGVuc2lvbiwgd2hpY2ggaXMgc29tZXRoaW5nIGl0IG5lZWRz CisgICAgICAgIHRvIGJlIGFibGUgdG8gZG8uIEluIHRoaXMgYnVnIHJlcG9ydCwgaXQgaXMgY29u ZmxhdGluZyB0ZXh0L2h0bWwgd2l0aAorICAgICAgICBhcHBsaWNhdGlvbi94LWV4dGVuc2lvbi1o dG1sLCBidXQgaXQgY291bGQganVzdCBhcyB3ZWxsIGNvbmZ1c2UgdGV4dC9odG1sIHdpdGgKKyAg ICAgICAgYXBwbGljYXRpb24veGh0bWwreG1sLCBjYXVzaW5nIHJlbmRlcmluZyBpc3N1ZXMuIEkg ZG9uJ3QgdGhpbmsgd2UgY2FuIHJlbW92ZSB0aGUgY29udGVudAorICAgICAgICBzbmlmZmluZy4K KworICAgICAgICAqIE5ldHdvcmtQcm9jZXNzL3NvdXAvTmV0d29ya0RhdGFUYXNrU291cC5jcHA6 CisgICAgICAgIChXZWJLaXQ6Ok5ldHdvcmtEYXRhVGFza1NvdXA6OmRpZEdldEZpbGVJbmZvKToK KwogMjAyMS0xMC0xNSAgR2FycmV0dCBEYXZpZHNvbiAgPGdhcnJldHRfZGF2aWRzb25AYXBwbGUu Y29tPgogCiAgICAgICAgIEltcG9ydCBBdXRoZW50aWNhdGlvblNlcnZpY2VzQ29yZSdzIHB1Ymxp YyBtb2R1bGUgYXMgd2VsbApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vz cy9zb3VwL05ldHdvcmtEYXRhVGFza1NvdXAuY3BwIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJv Y2Vzcy9zb3VwL05ldHdvcmtEYXRhVGFza1NvdXAuY3BwCmluZGV4IDA1NWUxNTA0YzM4NTBmZjI5 M2ZkODUyMDE5NzQ2ZDg0OTBkZWUyMmMuLmIyMGFhNTFhMGY4NGY5NWFkOGYwYjc4MDdkNzQxNzFh ZGM1MjA1YTMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3Mvc291cC9O ZXR3b3JrRGF0YVRhc2tTb3VwLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNz L3NvdXAvTmV0d29ya0RhdGFUYXNrU291cC5jcHAKQEAgLTE2ODUsMTIgKzE2ODUsMTEgQEAgdm9p ZCBOZXR3b3JrRGF0YVRhc2tTb3VwOjpkaWRHZXRGaWxlSW5mbyhHRmlsZUluZm8qIGluZm8pCiAg ICAgICAgIG1fcmVzcG9uc2Uuc2V0TWltZVR5cGUoInRleHQvaHRtbCIpOwogICAgICAgICBtX3Jl c3BvbnNlLnNldEV4cGVjdGVkQ29udGVudExlbmd0aCgtMSk7CiAgICAgfSBlbHNlIHsKLSAgICAg ICAgLy8gR3Vlc3MgbWltZS10eXBlIGZyb20gVVJMIHBhdGggYW5kIGZhbGwtYmFjayB0byBtaW1l LXR5cGUgZGV0ZWN0ZWQgYnkgR2lvL3NoYXJlZC1taW1lLWluZm8gb3RoZXJ3aXNlLgotICAgICAg ICBhdXRvIG1pbWVUeXBlID0gTUlNRVR5cGVSZWdpc3RyeTo6bWltZVR5cGVGb3JQYXRoKG1fcmVz cG9uc2UudXJsKCkucGF0aCgpLnRvU3RyaW5nKCkpOwotICAgICAgICBpZiAobWltZVR5cGUgPT0g ZGVmYXVsdE1JTUVUeXBlKCkpCi0gICAgICAgICAgICBtaW1lVHlwZSA9IGV4dHJhY3RNSU1FVHlw ZUZyb21NZWRpYVR5cGUoZ19maWxlX2luZm9fZ2V0X2NvbnRlbnRfdHlwZShpbmZvKSk7Ci0KLSAg ICAgICAgbV9yZXNwb25zZS5zZXRNaW1lVHlwZShtaW1lVHlwZSk7CisgICAgICAgIGNvbnN0IGdj aGFyKiBjb250ZW50VHlwZSA9IGdfZmlsZV9pbmZvX2dldF9jb250ZW50X3R5cGUoaW5mbyk7Cisg ICAgICAgIG1fcmVzcG9uc2Uuc2V0TWltZVR5cGUoZXh0cmFjdE1JTUVUeXBlRnJvbU1lZGlhVHlw ZShjb250ZW50VHlwZSkpOworICAgICAgICBtX3Jlc3BvbnNlLnNldFRleHRFbmNvZGluZ05hbWUo ZXh0cmFjdENoYXJzZXRGcm9tTWVkaWFUeXBlKGNvbnRlbnRUeXBlKSk7CisgICAgICAgIGlmICht X3Jlc3BvbnNlLm1pbWVUeXBlKCkuaXNFbXB0eSgpKQorICAgICAgICAgICAgbV9yZXNwb25zZS5z ZXRNaW1lVHlwZShNSU1FVHlwZVJlZ2lzdHJ5OjptaW1lVHlwZUZvclBhdGgobV9yZXNwb25zZS51 cmwoKS5wYXRoKCkudG9TdHJpbmcoKSkpOwogICAgICAgICBtX3Jlc3BvbnNlLnNldEV4cGVjdGVk Q29udGVudExlbmd0aChnX2ZpbGVfaW5mb19nZXRfc2l6ZShpbmZvKSk7CiAgICAgfQogfQo=