[pkg-wine-party] Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

Fri Dec 9 15:44:52 UTC 2016

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