WineHQ Bugzilla – Bug 25481 – Desktop launchers generated by Steam use unregistered URL handler

Bugzilla

Last modified: 2014-02-20 12:37:47 UTC

Desktop launchers generated by Steam use unregistered URL handler

Bug 25481 - Desktop launchers generated by Steam use unregistered URL handler


Summary:	Desktop launchers generated by Steam use unregistered URL handler

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	shell32
Version:	1.3.8
Hardware:	x86 Linux

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-12-11 01:11 UTC by Javier Kohen
Modified:	2014-02-20 12:37 UTC (History)
CC List:	5 users (show)

See Also:
Regression SHA1:
Fixed by SHA1:	1a3b85a5bda240ef96a678781ef1a98e595932dd
Distribution:	---
Staged patchset:

Attachments
Patch winemenubuilder to use start.exe instead of winebrowser for urls (1.08 KB, patch) 2011-08-10 14:35 UTC, Per Johansson	Details \| Diff
View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Javier Kohen 2010-12-11 01:11:44 UTC

After upgrading Steam to the new UI, the application icons Steam generates have a launch command doesn't work with Wine, because the steam URL handler isn't registered (at least in GNOME):

[Desktop Entry]
Name=Uplink
Exec=env WINEPREFIX="/home/user/.wine" wine winebrowser steam://rungameid/6910
Type=Application
StartupNotify=true

$ wine winebrowser steam://rungameid/1510
fixme:ntoskrnl:KeInitializeTimerEx stub: 0x110f60 0
gvfs-open: steam://rungameid/1510: error opening location: La ubicación
especificada no está soportada
(That translates to "unsupported location.")

A desktop file generated with the older UI looks like this and launches the game fine:

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Deus Ex Game of the Year Edition
Exec=env WINEPREFIX="/home/user/.wine" wine "C:\\Archivos de
programa\\Steam\\steam.exe" -applaunch 6910
Type=Application
StartupNotify=true
Path=/home/user/.wine/dosdevices/c:/Archivos de programa/Steam
Icon=/home/user/.local/share/icons/b45c_hdtp.png

There's a workaround for this problem. Add an URL handler
for the steam protocol to your desktop environment and have it run the following:
wine "c:\\Archivos de Programa\\steam\\steam.exe" %s

Comment 1 nE0sIghT 2011-05-15 14:13:46 UTC

This is still issue in 1.3.20

Comment 2 byteframe 2011-07-07 19:31:21 UTC

I think can confirm this is still present in 1.3.23.

The desktop launcher created has:
Exec=env WINEPREFIX="/home/byteframe/.wine" wine winebrowser steam://rungameid/6980

Clicking on it does nothing, running the command (minus the 'env') returns: 

gvfs-open: steam://rungameid/6980: error opening location: The specified location is not supported.

Comment 3 Per Johansson 2011-08-08 17:23:22 UTC

winebrowser has no support for URLs registered by applications inside the wine prefix. It should have, however. The workaround mentioned only works if you only have a single wine prefix, and not at all on OS X (which has native Steam).

Comment 4 Per Johansson 2011-08-08 17:24:25 UTC

Comment 5 Per Johansson 2011-08-10 14:35:03 UTC

Created attachment 35913 [details]
Patch winemenubuilder to use start.exe instead of winebrowser for urls

Actually start.exe does the right thing, so the problem seems to be that winemenubuilder is hard coded to winebrowser. Try the attached patch (it works for me). It will only work for newly created desktop items (i.e. go into steam and select "Create desktop shortcut" again)

Comment 6 Austin English 2013-11-13 16:51:44 UTC

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).

Comment 7 Per Johansson 2013-11-14 07:36:14 UTC

I submitted that patch. I believe it went into early 1.5. Only works on new shortcuts though.

Comment 8 Bruno Jesus 2014-02-06 05:21:35 UTC

This is the commit:
http://source.winehq.org/git/wine.git/commitdiff/1a3b85a5bda240ef96a678781ef1a98e595932dd

So, can we mark this as fixed?

Comment 9 Per Johansson 2014-02-07 06:56:17 UTC

IMO yes. The pre-existing shortcuts issue has probably mostly solved itself by the passing of time.

Comment 10 Austin English 2014-02-07 13:18:59 UTC

(In reply to comment #9)
> IMO yes. The pre-existing shortcuts issue has probably mostly solved itself
> by the passing of time.

Agreed.

Comment 11 Alexandre Julliard 2014-02-20 12:37:47 UTC

Closing bugs fixed in 1.7.13.