control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=28159 control: tags -1 - moreinfo unreproducible
The upstream bugreport #28159 requests to not create *native* associations for xml and html. But it also states that for *Wine* to know how to open these file types with a native application is indeed wanted. I'll followup there soon. There's another bugreport which goes even further: https://bugs.winehq.org/show_bug.cgi?id=19182 "Allow to completely disable MIME-type and application integration" Reproduce/ freedesktop specification: ===================================== To reproduce remove all (related content in) mimeapps.list (see [1] for possible locations). Here this was: ~/.config/mimeapps.list (if user clicks *in* firefox on "make default") ~/.local/share/applications/mimeapps.list (if user clicks *in* chromium on "make default") /usr/share/applications/gnome-mimeapps.list (pkg:gnome-session-common) @Vincent: I assume you have no mimeapps.list on your system that sets a default for text/html. Right? Then (going *literally* by the freedesktop specification) your report is not valid, because defaults need to be set in mimeapps.list. .desktop files and mimecache.info do not set defaults, they only tell the system about available programs. See the spec at [2]. However, if no default is specified in a mimeapps.list, then .desktop files in /home (as created by Wine) seem to take precedence before system .desktop files (e.g. /usr/share/applications/firefox-esr.desktop). See the spec at [3]. Affected systems: ================= For now I assume systems are safe from this if they have a mimeapps.list that has a text/html entry. According to [4] this is only Gnome and Cinnamon. I wonder why we don't get permanent reports about this e.g. by KDE users. @Vincent: When did you first observe this behavior? Just now or for a longer time? I didn't find any mime/(free)desktop related changes since Wine 1.8.0. Can you please also try with a fresh user with an empty /home? I'd expect Wine to overtake after a "wineboot && winecfg" (still need to investigate when exactly the desktop files are (re-)created). I assume there's some more magic that I don't know about yet. Crash and endless loop: ======================= Here and in #28159 Wine hangs in an endless loop then, instead of aborting like it did for you: On 22.11.2016 16:39, Vincent Lefevre wrote: > cventin:~> xdg-open foo.html > wine: invalid directory "/home/vlefevre/.wine" in WINEPREFIX: not an absolute path > Aborted (core dumped) For me this looks like an absolute path - what is Wine complaining about? If you can reproduce this specific error please file a new bug about this. Let's keep this bug for Wine becoming default app for .html files, independently of what happens later. winebrowser / opens in notepad: =============================== According to [5] the Winebrowser "attempts to open a URL in the native operating system's default protocol handler." So, assuming that this is also about .html files, the Wine project intends to use the native browser for this. Good. However we want to use the native browser directly for .html files, not indirectly via Wine. If I keep ~/.local/share/applications/wine-extension-htm.desktop, but remove this entry from ~/.local/share/applications/mimeinfo.cache: text/html=wine-extension-htm.desktop; ... then "xdg-open foo.html" opens in Wine's notepad. Definitely not useful, needs further investigation. Setting of /etc/alternatives/x-www-browser: =========================================== This is (unfortunately) mostly irrelevant for handling media types (mime), because these are based on .desktop files, which usually specify specific programs. However I wonder if it would be useful to have an /usr/share/applications/mimeapps.list to reference x-www-browser on all Debian systems (beyond the scope of this bug). Workaround: =========== To generally disable winemenubuilder, which creates these (and other!) entries, see [6]. Probably set in your .bashrc: export WINEDLLOVERRIDES="winemenubuilder.exe=d" To fix affected systems (as James Lu already wrote), see [7]. Greets jre [1] https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s02.html [2] https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s09.html [3] https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s04.html, however I think this lacks details. There's also https://www.freedesktop.org/wiki/Specifications/mime-apps-spec/, but the links there are dead. Need to investigate. [4] https://codesearch.debian.net/search?q=text%2Fhtml+path%3A.*mimeapps.list [5] https://wiki.winehq.org/Winebrowser [6] https://wiki.winehq.org/FAQ#How_can_I_prevent_Wine_from_changing_the_filetype_associations_on_my_system_or_adding_unwanted_menu_entries.2Fdesktop_links.3F [7] https://wiki.winehq.org/FAQ#How_do_I_wipe_the_virtual_Windows_installation.3F Upstream bugreports related to this general topic: ================================================== https://bugs.winehq.org/show_bug.cgi?id=3548 .lnk file is created on the desktop together with the program icon... https://bugs.winehq.org/show_bug.cgi?id=25166 Multiple mime type handling registered for different file extensions https://bugs.winehq.org/show_bug.cgi?id=28158 winemenubuilder forces lower case when searching fd.o mime database https://bugs.winehq.org/show_bug.cgi?id=28160 winemenubuilder should have a consistent way to deal with extensions that have multiple (native) mimetypes https://bugs.winehq.org/show_bug.cgi?id=33912 Remove All Wine Home Content - Button