TBA: open with Tor Browser does not work if Tor Browser is not open already
This happens to me with Tor Browser for Android alpha downloaded from our website in LineageOS. My system is in Spanish and Tor Browser detects the locale in the settings at least.
Steps to reproduce:
-
Make sure you have Tor Browser closed
-
Click on a link on your email or similar to trigger the 'open with Tor Browser always, only once'.
-
Select Tor Browser. You get the pretty purple screen with the 'Conecta' button.
-
Click Connect. The Tor Browser homepage appears.
Your link is forgotten!
-
Go back to your email, and click again on the link.
-
Select Tor Browser
-
The link is opened in Tor Browser.
What should happen instead:
- Tor Browser should open the first time with the link, after connecting, instead of the homepage. It seems it forgets the link during the connection process.
Activity
Replying to sysrqb:
hmm. I'm guessing the requested webpage isn't opened in another tab during the first part, correct? The homepage is loaded and displayed, but i wonder if the requested webpage is available in another tab.
Nope. This looks like it's a race condition (where I'm guessing we almost always lose). The requested URL should be opened in a new tab during startup, but then we "sanitize" all tabs around the same time as a way of "cleaning up" the previous session in case the app was killed (or crashed) for some reason. I'll test this and confirm our clean-up code is causing this.
It seems this is solved after disabling "Clear private data on exit" entries (Settings -> Privacy -> Clear private data on exit -> (uncheck Open tabs)).
The new behavior is interesting. After bootstrapping completes, I see an error page (because the initial page load failed...because tor wasn't bootstrapped). Next, the page reload automatically because we force this after bootstrapping completes.
- I think we should re-consider our decision on implementing this hack at startup from #28507 (moved)
- The UX is a little ugly because it tries loading the page when tor isn't running. I wonder if we can easily delay the load until after bootstrap completes.
Closed #30661 (moved) as duplicate.
Trac:
Cc: gk to gk, xbbkI have a branch ready for review in my repo,
bug30573_8.5_01. This simply delays loading the requested page until after all tabs are "sanitized" (closed) and tor finishes bootstrapping. I have another branch for the alpha, I'll post that soon.This branch creates an event dispatch listener for events
Sanitize:FinishedandTor:Ready. It begins by checking the current status (if sanitizing tabs is enabled and if tor is not started). These values are used for initializing the event listener. The listener listens for a "fake" event (Tor:CheckIfReady) as well, which is emitted immediately after creation, in case tor is running already and tabs won't be sanitized.After the necessary events are received, then the tab is loaded. This prevents both the tab loading before all tabs are closed during the sanitization (therefore closing this new tab, as well), and this prevents loading the tab before tor is ready and showing a proxy network error page while the tab is reloading (which we force after tor bootstrap completes). Overall, this seems like a better experience.
Trac:
Keywords: N/A deleted, TorBrowserTeam201905R added
Status: new to needs_reviewAfter this branch lands on
8.5branch, I'll forward port it to9.0, and that should land on top of the patch for #24920 (moved).-
I think we want to test this in an alpha first. I am bit wary pushing too much directly to stable in particular as we want to avoid doing another point release next week to fixup things if possible. Marking that ticket for revision for now.
Trac:
Keywords: TorBrowserTeam201907R deleted, TorBrowserTeam201907 added
Status: needs_review to needs_revision -
Okay, I know it's late but I finally found time to test that with the 9.0a4 release candidate. It does not seem to work for me. :( The URL shows up in the URL bar but nothing happens. Interestingly, the number of open tabs is 0, which seems to indicate that there is no private tab available.
What is worse, though, is that it seems to work for me with the current alpha, 9.0a3. Is that a side-effect of fixing #24920 (moved)? Or I am just lucky with that version?
(Nit: s/Sanitizing is enable/Sanitizing is enabled/)
This made it onto
tor-browser-60.8.0esr-9.0-1(commit 129f38a67ac6db0b80a371d3f44fff30a042e5a1).Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201907R deleted, N/A added Replying to gk:
Okay, I know it's late but I finally found time to test that with the 9.0a4 release candidate. It does not seem to work for me. :( The URL shows up in the URL bar but nothing happens. Interestingly, the number of open tabs is 0, which seems to indicate that there is no private tab available.
Yes. This is concerning. I saw this bug during my testing too, and I thought it was solved by correcting how it detects "Sanitize Tabs" is enabled.
The cause of the bug was the "requested url" was put into the url bar at the beginning of the startup process, but this is only for UX. The page is not actually requested and loaded until later in the startup process. The patch for this ticket delays page load further by waiting until sanitization is complete, tor is bootstrapped, and Gecko is loaded (or if sanitizing tabs is disabled, then it only waits until tor is bootstrapped and Gecko is loaded).
-
#32130 (moved) is a duplicate.
Trac:
Cc: gk, xbbk to gk, xbbk, doctorer mentioned in issue #30661 (moved)
mentioned in issue #32130 (moved)
