[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: wine-bugs(a)winehq.org ReportedBy: wine(a)rodrigosilva.com 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #1 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-08-22 20:56:26 CDT --- Wine really shouldn't associate with html/xml... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 Dmitry Timoshkov <dmitry(a)baikal.ru> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 --- Comment #2 from MestreLion <wine(a)rodrigosilva.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 --- Comment #3 from Austin English <austinenglish(a)gmail.com> 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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #4 from Jerome Leclanche <adys.wh(a)gmail.com> 2013-11-15 14:35:47 CST --- Yeah most likely still an issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28159 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov(a)gmail.com --- Comment #5 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (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)? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28159 --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28159 Jens Reyer <jre.winesim(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim(a)gmail.com --- Comment #7 from Jens Reyer <jre.winesim(a)gmail.com> --- 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". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28159 --- Comment #8 from Jens Reyer <jre.winesim(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28159 --- Comment #9 from Jens Reyer <jre.winesim(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org