Tor Browser Script can't be launched from the Linux desktop
In Unity (Ubuntu) and GNOME 3, it is not possible to start Tor Browser through the graphical file manager. When double-clicking on start-tor-browser, an editor will pop-up by default.
One user suggested through the help desk that we ship a .desktop file. In GNOME 3, users are prompted to confirm because it's an unknown application, but this is still much better.
Here's a minimal .desktop that should probably be enhanced with comments, translations, icons:
[Desktop Entry]
Type=Application
Name=Tor Browser
Terminal=false
Exec=sh -c '"$(dirname "$*")"/start-tor-browser' dummy %kAlso inspired by https://unix.stackexchange.com/q/144422
Activity
I wrote one for some friends a couple of weeks ago. I agree that we should be shipping this as it makes it far, far easier for users.
[Desktop Entry] Version=4.0 Name=Tor Browser Comment=Tor Browser is +1 for privacy and -1 for mass surveillance Exec=bash -c "export PATH=$PATH:`dirname %k`; start-tor-browser" Icon=/usr/lib/firefox/browser/icons/mozicon128.png Terminal=false Type=Application Categories=Utility;Application;This is tested and working in Ubuntu 14.04 with Unity (default).
Assuming Mike meant the example in comment:1 to be up for review I think we can't take the icon path unmodified as it 1) would point to a Firefox icon which we don't want and 2) that path is not existing on all Linux systems. Furthermore, we'd need to think a bit harder at least about the Version entry.
To be useful, wouldn't this .desktop file need to be installed outside of the TBB directory, e.g. in ~/.local/share/applications/? If so, given the regular TBB install process can't do that, how do we tell the user they should go through this additional step? And how does it play with the incremental upgrade process?
Replying to intrigeri:
To be useful, wouldn't this .desktop file need to be installed outside of the TBB directory, e.g. in ~/.local/share/applications/?
No. Shipping such a
.desktopfile will allow users to start Tor Browser by double-clicking on it in their file manager. That's why theExecline is a bit convoluted.
Kathy and I experimented a little with this on an Ubuntu 14.04 system (Unity/GNOME). We could not find a way to use a relative path for the icon; apparently that is not supported. Some people have used the Exec command to insert the full path after Icon= in the .desktop file the first time it is opened (essentially, by using a self modifying script). That is ugly but would make it so the correct icon is shown after you open the browser once.
Another issue is that the Tor Browser updater cannot touch anything in the top-level directory. We worked around that problem by placing our org.torproject.browser.desktop file in the Browser/ directory and creating a symlink above that pointed to it (much like we do with start-tor-browser). But then the bash command within the .desktop file needs to handle the case where either the symlink or real .desktop object is opened by the user. Here is what we came up with, although it does not handle spaces within the installation path:
[Desktop Entry] Type=Application Name=Tor Browser Comment=Tor Browser is +1 for privacy and -1 for mass surveillance Categories=Utility;Application; Exec=bash -c "TBDIR=`dirname %k`; if [ `basename $TBDIR` = 'Browser' ]; then TBDIR=`dirname $TBDIR`; fi; $TBDIR/Browser/start-tor-browser"If we do ship a .desktop file, we may want to remove the start-tor-browser symlink since it might cause user confusion (which thing should I double-click?)
So, this almost works as a single file if I do:
[Desktop Entry] Type=Application Name=Tor Browser Comment=Tor Browser is +1 for privacy and -1 for mass surveillance Categories=Utility;Application; Exec=bash -c "TBDIR=`dirname %k`; if [ `basename $TBDIR` = 'Browser' ]; then TBDIR=`dirname $TBDIR`; fi; $TBDIR/Browser/start-tor-browser"Except that xdg-open decides to open it in a text editor instead of launching the app.. I also tried 'nautilus', and it opened the containing folder instead of running the Exec line. Any other ideas?
-
Wow, there's some serious Linux wankery preventing .desktop files not to be executable from the shell, and only work if clicked on. See https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/378783 and https://bugzilla.gnome.org/show_bug.cgi?id=343896.
However, we may be able to do something like: https://stackoverflow.com/questions/6020106/hashbang-for-gnome-desktop-files https://askubuntu.com/questions/5172/running-a-desktop-file-in-the-terminal
But it will need a relative path to that execdesktop wrapper script. Needs more testing/hacking...
-
Actually, if we decide to do the self-modifying method to get the absolute path to the icon, how do we handle interactions with the updater? Is there a way to flag a file as non-incremental in the event of an update? Otherwise, if we need to change the .desktop file in the future, the incremental update will fail the CRC check for the file for all Linux users, and all of them will download the full update for that release.
-
Replying to mikeperry:
Actually, if we decide to do the self-modifying method to get the absolute path to the icon, how do we handle interactions with the updater? Is there a way to flag a file as non-incremental in the event of an update?
Yes, although it involves patching tools/update-packaging/make_incremental_update.sh in the Mozilla code. Look in that file for requested_forced_updates and add the path of the file you want to always overwrite. Adding a line like this might work: requested_forced_updates="$requested_forced_updates Browser/.desktop" It does not matter that file does not exist on Mac and Linux; the requested_forced_updates list is only checked if the file exists in the complete MAR file associated with the newer version of the browser.
-
Ok, I think I've got this working fairly well! See https://gitweb.torproject.org/user/mikeperry/tor-browser-bundle.git/commit/?h=bug13375&id=08ea97411adede0c6ea701065697cad2f1599f26 and https://gitweb.torproject.org/user/mikeperry/tor-browser.git/commit/?h=bug13375&id=5e4af3a1fc25f1f0d56ab2c1d789757b8eb961bf
For a description of all the ways that TBB can now be launched with this .desktop-as-a-script mechanism, see the comments atop the .desktop file: https://gitweb.torproject.org/user/mikeperry/tor-browser-bundle.git/tree/RelativeLink/start-tor-browser.desktop?h=bug13375&id=08ea97411adede0c6ea701065697cad2f1599f26 - let me know if this description is unclear or could be improved in any way.
Spaces in the installation path are supported, but at the expense of not allowing the user to launch directly from the Browser directory.. Hopefully that is not common, especially since we use the "web-browser" default desktop icon, which should strongly indicate that the user should click the thing there to start it, instead of wandering into Browser.
Trac:
Keywords: MikePerry201502R, TorBrowserTeam201503 deleted, MikePerry201503 added
Status: assigned to needs_review -
I thought of a couple of bad corner cases:
-
Because it is a symbolic link, the Nautilus file manager doesn't properly handle dragging the .desktop file around between directories or to the Desktop. It actually moves the relative symbolic link without updating it, causing it to become a broken link.
-
Users who update TBB from a version without this .desktop file won't get it in their TBB directory after update. It's a shame they have to miss out on this usability improvement. They may not ever know it even exists.
Both of these make me think it is better to actually have start-tor-browser.desktop be a full-fledged file, and a copy of the version in Browser/start-tor-browser.desktop. The start-tor-browser script can simply overwrite (or create) the ../start-tor-browser.desktop file as a proper file upon each invocation. That way, if we need to update it via the updater, the .desktop file will actually get re-written on the next invocation. Since we're modifying it anyway, this doesn't seem that much crazier than what we're already doing here, and seems strictly better.
I just pushed a fixup commit to that branch to fix this (see https://gitweb.torproject.org/user/mikeperry/tor-browser-bundle.git/commit/?h=bug13375&id=a2260918d993aaa3ea14334a59bd634711bde8dc). While I was at it, I made it possible to run start-tor-browser.desktop directly from the Browser/ subdirectory in the file manager, in case users end up wandering in their file browser.
I think this also means that we can omit start-tor-browser.desktop from the forced full updates, so my tor-browser.git branch is no longer relevant (though independently, I think it is good to force a full update of start-tor-browser, because it is probably common for people to tweak that file, and that shouldn't cause incrementals to fail for them).
-
-
One more annoying property: this causes a terminal window to open by default, and if the user closes that terminal, the browser dies.
I've noticed that start-tor-browser still has a --debug option.. Perhaps that option should be what governs the output+terminal being present+required, otherwise it gets sent to /dev/null? Right now it seems that --debug does nothing.
Replying to mikeperry:
One more annoying property: this causes a terminal window to open by default, and if the user closes that terminal, the browser dies.
I've noticed that start-tor-browser still has a --debug option.. Perhaps that option should be what governs the output+terminal being present+required, otherwise it gets sent to /dev/null? Right now it seems that --debug does nothing.
I can easily fix up my patch for #11751 (moved), which
disowned the child firefox process. I'll do it so that the--debugflag that we don't currently pass to firefox will enable a logfile, and otherwise all output will go to/dev/null.Trac:
Cc: N/A to isisReplying to isis:
Replying to mikeperry:
One more annoying property: this causes a terminal window to open by default, and if the user closes that terminal, the browser dies.
I've noticed that start-tor-browser still has a --debug option.. Perhaps that option should be what governs the output+terminal being present+required, otherwise it gets sent to /dev/null? Right now it seems that --debug does nothing.
I can easily fix up my patch for #11751 (moved), which
disowned the child firefox process. I'll do it so that the--debugflag that we don't currently pass to firefox will enable a logfile, and otherwise all output will go to/dev/null.Okay, your patch is a single commit in my
bug13375-bug11751-disown-browser-processbranch.-
Ok, I merged Isis's commit into my branch, and tweaked some more things:
- I got rid of the terminal window.
- I added a check to prevent double-launching the browser on non-zero exit codes.
- I improved the --help message and behavior.
- I merged Robert Ransom's stdout+stderr+terminal cleanups from #12468 (moved).
The branch to review is still https://gitweb.torproject.org/user/mikeperry/tor-browser-bundle.git/log/?h=bug13375
FYI: After these changes, I re-tested all of the various ways of moving this thing around, launching it from the file manager and shell, and making sure it still supports spaces in the install path. It still seems good to me.
-
Some random feedback after testing some things:
-
I got a bit nervous on my slow machine after seeing no output anymore on the command-line and no window popped up for several seconds after starting with
./start-tor-browser.desktop. Maybe having command-line output is an expert thingy and I should use--debuginstead. -
Starting with the second start from command-line I get a "Firefox is already running..." popup although the start-up works as expected. This even happens if I close Tor Browser and wait some minutes (it turns out this actually happens when clicking on the launcher as well).
-
Using
--debughas the funny consequence that Tor Browser gets started twice in a row: After closing the first Tor Browser it gets relaunched immediately. -
Have you looked whether our (core) documentation needs some update? I bet a bunch of users will get confused looking at
start-tor-browser.desktopwhile expectingstart-tor-browserto be there. -
Having the non-Tor Browser icon first seems suboptimal to me as it might confuse users (What has this thing to do with Tor Browser as it does not even look like it?). I mean we replace the icon in any case with the Tor Browser one. Why not shipping the latter then by default?
I have not looked at your code yet. The needs_revision is only for 2) and 3).
Trac:
Status: needs_review to needs_revision -
-
Ok, I pushed a commit to https://gitweb.torproject.org/user/mikeperry/tor-browser-bundle.git/log/?h=bug13375 to deal with issues 1 through 3. I was able to reproduce your issues beforehand, and they seem fixed for me now.
For 4, we should indeed update the documentation when 4.5 goes stable. I think we have quite of docs to update for 4.5, I bet.
For 5, we can't set the official TBB icon in the .desktop file because the FreeDesktop spec does not allow any relative paths for either icons or execution. That's why this whole thing is a pile of hacks and shell black magic. We set the icon to the official one by using the absolute path to the current directory after first invocation. For an initial icon, the generic web-browser icon seemed a better choice than the default "no icon provided" image.
-
Btw, I have decided that we shouldn't mess with trying to force-update the startup scripts just yet (see #15456 (moved)), so the tor-browser.git branch here is no longer relevant at all. The tor-browser-bundle.git bug13375 branch is now the only one that needs review.
-
A couple of comments after testing again:
-
If I drag the .desktop file to my task bar before launching Tor Browser the first time the icon never gets updated after I am successfully using Tor Browser which might be confusing to users.
-
If I decide to put later on a shortcut on my desktop as well this succeeds but the price is a deleted shortcut in my taskbar (which should not happen as a) it does not happen the other way around and b) both should not depend on each other in this way).
-
If I drag the default icon to my desktop (+ the task bar) I won't be able to start Tor Browser without the command-line either way. I bet this is at least surprising to some users as they might be used to prepare their shortcuts before starting applications for the first time.
-
While testing a while I forgot the open Tor Browser folder and played with the shortcuts. Then I deleted them as I did not need them anymore but was suddenly puzzled as the .desktop file in Tor Browser was gone as well (leading to the question how to start it now). I wonder how many users will be affected by this thinking that they are just dragging links around. On the other hand: I am using Linux computers not that way so maybe it is/was only an issue for me
I'd like to see at least a revision that fixes 2) if possible not sure what else is fixable given the constraints we have.
Trac:
Status: needs_review to needs_revision -
mentioned in issue #13717 (moved)
mentioned in issue #15456 (moved)
mentioned in issue #15532 (moved)
mentioned in issue #15598 (moved)
mentioned in issue tpo/applications/tor-browser#15456 (closed)