[Bug 28159] New: [integration] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

Summary: [integration] winebrowser associations with *.htm and
                    *.xml may cause native system to infinite loop
           Product: Wine
           Version: 1.3.26
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: programs
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Out of the box, wine comes with *.htm and *.xml associations for winebrowser.
And wine publishes those associations in native system, creating
wine-extension-htm.desktop and wine-extension-xml.desktop. Those 2 appear in
all native's "Open With" dialoags as legit options. But, if chosen, system
enters an infinite loop (*.htm file -> start.exe /ProgId htmfile -> winebrowser
-> xdg-open -> start.exe ...)

To prevent this, and still keep a way to allow wine apps to launch files in
native apps AND allow native apps to launch files in wine apps, wine should
implement a way to inhibit winemenubuilder to create native associations for
certain extensions (in this case, *.htm and *.xml)

That can be done in several ways (hardcode blacklisting winebrowser.exe is the
easiest, but its lame), and my suggestion is this:

winemenubuilder should not create associations if the class is in
"WineImportedExtension.xxx" format. Example:

[HKEY_CLASSES_ROOT.htm]
@="WineImportedExtension.htm"

[HKEY_CLASSES_ROOT\WineImportedExtension.htm\shell\open\command]
@="C:\windows\system32\winebrowser-gui.exe "%1""

WineImportedExtension is a way to say: "this is not an extension handled by a
windows app. It is an extension imported from native system. So DO NOT create
an association for it in native... its already there"

To original class, "htmlfile", can stay untouched.

If, later, user installs a windows app that handles that extension, it will
overwrite the default "WineImportedExtension.xxx" to its own, and
winemenubuilder will correctly create a native *.htm association to indicate
that now there is a windows app to actually handle that.

[Bug 28159] [integration] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Jerome Leclanche  2011-08-22 20:56:26 CDT ---
Wine really shouldn't associate with html/xml...

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |integration
            Summary|[integration] winebrowser   |winebrowser associations
                   |associations with *.htm and |with *.htm and *.xml may
                   |*.xml may cause native      |cause native system to
                   |system to infinite loop     |infinite loop

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

--- Comment #2 from MestreLion  2011-08-23 08:07:06 CDT ---
(In reply to comment #1)
> Wine really shouldn't associate with html/xml...

It does so for a (great) convenience, to allow wine apps to open html pages
(and also http: links) in native browser.

The association itself is not bad... there are many scenarios where association
with winebrowser is desirable: mail client opening attachments, P2P like
uTorrent or Soulseek opening downloaded files, etc.

The problem is only when winemenubuilder creates *native* associations for
these too. There should be a way to tell winebrowser not to publsh imported
extensions... hence my suggestion for a WineImportedExtension prefix to the
classes.

If you find current behavior is problematic, can you please confirm or vote
this bug?

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

--- Comment #3 from Austin English  2013-11-13 16:51:03 CST ---
This is your friendly reminder that there has been no bug activity for 2 years.
Is this still an issue in current (1.7.6 or newer) wine? If so, please attach
the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #4 from Jerome Leclanche  2013-11-15 14:35:47 CST ---
Yeah most likely still an issue.

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

http://bugs.winehq.org/show_bug.cgi?id=28159

Damjan Jovanovic  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from Damjan Jovanovic  ---
(In reply to MestreLion from comment #2)
> (In reply to comment #1)
> The problem is only when winemenubuilder creates *native* associations for
> these too.

In my tests, that no longer happens: winemenubuilder reuses Freedesktop's
text/html instead of creating application/x-wine-extension-htm[l].

Can you please confirm if it's still a problem for you on a clean install
(meaning, ideally, create a new user with a fresh, empty home directory, and
test using that user)?

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

https://bugs.winehq.org/show_bug.cgi?id=28159

--- Comment #6 from Austin English  ---
This is your friendly reminder that there has been no bug activity for over a
year. Is this still an issue in current (1.7.51 or newer) wine?

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

https://bugs.winehq.org/show_bug.cgi?id=28159

Jens Reyer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #7 from Jens Reyer  ---
Created attachment 56780
  --> https://bugs.winehq.org/attachment.cgi?id=56780
Don't create native file type associations.

This drops the "-a" switch from winemenubuilder in wine.inf and in
dlls/shell32/changenotify.c. That switch otherwise causes the freedesktop file
type associations and the mime database to be (re-)generated.

Unfortunately this breaks creating them manually with "wine winemenubuilder -a
-r".

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

https://bugs.winehq.org/show_bug.cgi?id=28159

--- Comment #8 from Jens Reyer  ---
Created attachment 56781
  --> https://bugs.winehq.org/attachment.cgi?id=56781
Blacklist some extensions for native file type association.

This blacklists all extensions that trigger a freedesktop file type association
from an empty prefix.

[Bug 28159] winebrowser associations with *.htm and *.xml may cause native system to infinite loop

https://bugs.winehq.org/show_bug.cgi?id=28159

--- Comment #9 from Jens Reyer  ---
One of our users ran into this with html files. However Wine crashed for him,
instead of infinite looping.
See https://bugs.debian.org/845334.
Debian wine 1.8.5-1

I could reproduce this and got an infinite loop, just like the original
submitter.
Debian wine-development 2.0~rc3-1

Reproduce:
==========
To reproduce remove all related content in your mimeapps.list files. Here this
was:

~/.config/mimeapps.list
  text/html=firefox-esr.desktop;chromium.desktop;
  (if user clicks *in* firefox on "make default")
~/.local/share/applications/mimeapps.list
  text/html=chromium.desktop
  (if user clicks *in* chromium on "make default")
/usr/share/applications/gnome-mimeapps.list
  text/html=firefox-esr.desktop;chromium.desktop;
  (installed by Gnome)

Our user uses no desktop environment, just fvwm. He has no system wide
mimeapps.list to set default applications, only his own handcrafted one which
doesn't cover html. This would have prevented this problem otherwise.

But if no default application is set the system just checks for available
applications. This information is gathered from the installed .desktop files,
and made available in a mimeinfo.cache file.

Wine is run by regular users, so it installs its desktop files in $HOME. Since
user configuration takes precedence over system configuration the system will
usually prefer associations with Wine over those with other applications.

E.g. ~/.local/share/applications/wine-extension-htm.desktop will be preferred
to /usr/share/applications/firefox-esr.desktop.

In summary, I assume today this problem doesn't affect many users because most
use desktop environments which specify lots of default applications. But
unfortunately as soon as no default application is specified the association
with Wine will be used in nearly every case, which is very unfortunate.

Patches:
========
I came up with two patches, just attached to this bug, but not submitted at
wine-patches.

With each of them Windows applications still know how to use native
applications to open a file, or use a new default from Windows (e.g. some
Windows app that I installed used the native "evince" to open a pdf, and after
I installed it in Wine "Foxit Reader").

Feedback about these patches is very welcome. I'd especially would like
something along Don-t-create-native-file-type-associations.patch, but with the
ability to create the associations manually. Then I'd be happy to submit it for
inclusion in Wine.

We will probably go with
Blacklist-some-extensions-for-native-file-type-associatio.patch in Debian for
now.