-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Open additional URLs with the same TorBrowser instance #395
base: main
Are you sure you want to change the base?
Conversation
When we looked at the history of issues about opening links with TorBrowser, we found torproject#103 where initially the feature to open links from other applications was added. Then some months later, the feature was removed again, as it was not working because of torproject#157 and torproject#175. The issues was back then (~4years ago), that when users had a normal Firefox running, urls got opened in the normal firefox insead of TorBrowser. That was because TorBrowser had the --no-remote flag set deep down in their code. In the meanwhile TorBrowser removed the explicit --no-remote flag, so we are able to use --allow-remote again. On top of that there is another issue when we want open urls with TorBrowser: If the LOGNAME is the same as the LOGNAME of the opened firefox, urls are still opened in the open firefox. But if we set the LOGNAME envrionment variable explicitly, we can make sure, that the url opens in the TorBrowser instead of a running Firefox. Should fix: torproject#245, torproject#259, torproject#380
I think this would solve number of open Debian bugs, such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910062 and friends :) |
You would need to add -allow-remote to the "Browser/firefox" script Regardless. torbrowser is always launched with the startup pages for each new window. Really torbrowser needs to have some way of opening a specified URL, both on the initial window, and in a currently running browser. It has been asked for for years! |
I can't reproduce your described behavior, did you tested my patch? I run my patch since March locally and it works. I don't get new windows every time I open links.
as it described in my initial description, this is not true anymore, that's why this patch is enough and no need to change anything in Tor Browser.
To be able to open multiple windows, we need to pass the new-window/new-tab command lines to start-tor-browser, but that's a different patch, after that got accepted. |
I tried adding it... Got python errors. I don't know python, (though I am an old - 30yo programmer -
|
nope you don't have to 'compile' it on your own. It is compiled, when you first need the file.
The issue is that python2 (EOF 1.Jan 2020) is used to run torbrowser-launcher and not python3. Not every distribution is using a symlink python -> python3, but every distribution should have installed python3. If you run the code with python3 it works. Or replace the following to be python2 complainant:
|
as stated in upstream ticket: https://trac.torproject.org/projects/tor/ticket/15185#comment:2 default "--no-remote" is set for good reason. |
When we looked at the history of issues about opening links with TorBrowser, we
found #103 where initially the feature to open links from other applications
was added. Then some months later, the feature was removed again, as it was not
working because of #157 and #175. The issues was back then (~4years ago), that
when users had a normal Firefox running, urls got opened in the normal firefox
insead of TorBrowser. That was because TorBrowser had the --no-remote flag set
deep down in their code.
In the meanwhile TorBrowser removed the explicit --no-remote flag, so we are
able to use --allow-remote again.
On top of that there is another issue when we want open urls with TorBrowser:
If the LOGNAME is the same as the LOGNAME of the opened firefox, urls are still
opened in the open firefox. But if we set the LOGNAME envrionment variable
explicitly, we can make sure, that the url opens in the TorBrowser instead of
a running Firefox.
Should fix: #245, #259, #380
WIP: it is not cleaned up, maybe we want revert 3f1146e and have the setting accept_links back.