Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#13375 closed enhancement (fixed)

Tor Browser Script can't be launched from the Linux desktop

Reported by: lunar Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-usability, tbb-helpdesk-frequent, tbb-usability-stoppoint-app, MikePerry201503, tbb-4.5-alpha, TorBrowserTeam201503R, GeorgKoppen201503R
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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 %k

Also inspired by https://unix.stackexchange.com/q/144422

Child Tickets

Change History (38)

comment:1 Changed 5 years ago by saint

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

comment:2 Changed 5 years ago by saint

Also, if we ship an icon image, it makes it easy to define an icon for it. This way, users can drag and drop it to their dock without worrying about confusing it with Firefox.

comment:3 Changed 5 years ago by dcf

My idea for this problem was to ship a little compiled program, essentially

int main()
{
        return system("./start-tor-browser");
}

A .desktop file is better, if it lets you set an icon.

comment:4 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201501R added
Status: newneeds_review

comment:5 in reply to:  4 Changed 5 years ago by gk

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.

comment:6 Changed 5 years ago by mikeperry

Keywords: tbb-usability-stoppoint-app added

comment:7 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201502R added; TorBrowserTeam201501R removed

comment:8 Changed 5 years ago by intrigeri

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?

comment:9 in reply to:  8 Changed 5 years ago by lunar

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 .desktop file will allow users to start Tor Browser by double-clicking on it in their file manager. That's why the Exec line is a bit convoluted.

comment:10 Changed 5 years ago by mikeperry

Keywords: MikePerry201502R added

comment:11 Changed 5 years ago by mcs

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

comment:12 Changed 5 years ago by mikeperry

Keywords: tbb-4.5-alpha added

comment:13 Changed 5 years ago by mcs

Status: needs_reviewneeds_information

comment:14 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201503 added

comment:15 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201503R added; TorBrowserTeam201502R removed

comment:16 Changed 5 years ago by mikeperry

FTR: I decided not to merge this for 4.5a4 because it still sounds janky and suboptimal. Should we perhaps repurpose this ticket for turning start-tor-browser.sh into a C program with proper icon resources for Linux/FreeDesktop?

comment:17 Changed 5 years ago by mikeperry

Summary: Let's ship a .desktop file in Tor Browser for LinuxTor Browser Script can't be launched from the Linux desktop

comment:18 Changed 5 years ago by mikeperry

So, this almost works as a single file if I do:

#!/usr/bin/env xdg-open

[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?

comment:19 Changed 5 years ago by mikeperry

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

comment:20 Changed 5 years ago by mikeperry

Owner: changed from tbb-team to mikeperry
Status: needs_informationassigned

comment:21 Changed 5 years ago by 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? 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.

comment:22 in reply to:  21 Changed 5 years ago by mcs

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.

comment:23 Changed 5 years ago by Jesse V.

This is not a problem in Linux Mint 17.1 under Cinnamon at least, so you're right that it only applies to those desktop environments. In my system, I am prompted what to do with an executable text file, and one of the options is to Run it. When this is selected, the browser opens.

comment:24 Changed 5 years ago by mikeperry

Keywords: MikePerry201503 added; MikePerry201502R TorBrowserTeam201503 removed
Status: assignedneeds_review

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.

comment:25 Changed 4 years ago by mikeperry

I thought of a couple of bad corner cases:

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

comment:26 Changed 4 years ago by 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.

comment:27 in reply to:  26 ; Changed 4 years ago by isis

Cc: isis added

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, which disowned the child firefox process. I'll do it so that the --debug flag that we don't currently pass to firefox will enable a logfile, and otherwise all output will go to /dev/null.

comment:28 in reply to:  27 Changed 4 years ago by isis

Replying 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, which disowned the child firefox process. I'll do it so that the --debug flag 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-process branch.

comment:29 Changed 4 years ago by mikeperry

Ok, I merged Isis's commit into my branch, and tweaked some more things:

  1. I got rid of the terminal window.
  2. I added a check to prevent double-launching the browser on non-zero exit codes.
  3. I improved the --help message and behavior.
  4. I merged Robert Ransom's stdout+stderr+terminal cleanups from #12468.

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.

comment:30 Changed 4 years ago by gk

Status: needs_reviewneeds_revision

Some random feedback after testing some things:

1) 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 --debug instead.

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

3) Using --debug has the funny consequence that Tor Browser gets started twice in a row: After closing the first Tor Browser it gets relaunched immediately.

4) Have you looked whether our (core) documentation needs some update? I bet a bunch of users will get confused looking at start-tor-browser.desktop while expecting start-tor-browser to be there.

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

comment:31 Changed 4 years ago by mikeperry

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.

comment:32 Changed 4 years ago by mikeperry

Status: needs_revisionneeds_review

comment:33 Changed 4 years ago by gk

Keywords: GeorgKoppen201503R added

I'll give that another round of testing and hopefully code review as well tomorrow.

comment:34 Changed 4 years ago by mikeperry

Btw, I have decided that we shouldn't mess with trying to force-update the startup scripts just yet (see #15456), 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.

comment:35 Changed 4 years ago by gk

Status: needs_reviewneeds_revision

A couple of comments after testing again:

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

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

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

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

comment:36 Changed 4 years ago by mikeperry

For the record, I think issues 2 and 4 are actually unity issues. They don't seem to happen with Gnome.

I tried to mitigate issue 1 and 3 by making the icon start off as "Tor Browser Setup" before first run in mikeperry/bug13375.

Last edited 4 years ago by mikeperry (previous) (diff)

comment:37 Changed 4 years ago by mikeperry

Resolution: fixed
Status: needs_revisionclosed

Ok, I pushed this to master for 4.5a5. Thanks for the help, everyone.

comment:38 Changed 4 years ago by mikeperry

(Incidentally, the branch I merged was mikeperry/bug13375-rebased+squashed, which has cleaner commits and messages. Its delta is identical to mikeperry/bug13375).

Note: See TracTickets for help on using tickets.