Opened 5 months ago

Last modified 3 months ago

#30573 needs_revision defect

TBA: open with Tor Browser does not work if Tor Browser is not open already

Reported by: emmapeel Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile
Cc: gk, xbbk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (17)

comment:1 Changed 5 months ago by gk

Keywords: tbb-mboile added; tba removed

comment:2 Changed 5 months ago by cypherpunks

gk seems to be celebrating TBA release ;)

comment:3 Changed 5 months ago by mcs

Keywords: tbb-mobile added; tbb-mboile removed

comment:4 Changed 5 months ago by 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.

comment:5 in reply to:  4 Changed 5 months ago by sysrqb

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.

comment:6 Changed 5 months ago by sysrqb

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.

  1. I think we should re-consider our decision on implementing this hack at startup from #28507
  2. 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.

comment:7 Changed 5 months ago by sysrqb

I'm going to approach this problem from ticket:28513#comment:4, and we'll see how well that goes.

comment:8 Changed 5 months ago by gk

Cc: xbbk added

Closed #30661 as duplicate.

comment:9 Changed 5 months ago by sysrqb

Keywords: TorBrowserTeam201905R added
Status: newneeds_review

I 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:Finished and Tor: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.

comment:10 Changed 5 months ago by sysrqb

After this branch lands on 8.5 branch, I'll forward port it to 9.0, and that should land on top of the patch for #24920.

comment:11 Changed 5 months ago by gk

Keywords: TorBrowserTeam201906R added; TorBrowserTeam201905R removed

Moving reviews over to June.

comment:12 Changed 4 months ago by gk

Keywords: TorBrowserTeam201907R added; TorBrowserTeam201906R removed

No reviews in June 2019 anymore, moving them.

comment:13 Changed 4 months ago by gk

Keywords: TorBrowserTeam201907 added; TorBrowserTeam201907R removed
Status: needs_reviewneeds_revision

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.

comment:14 Changed 4 months ago by sysrqb

Status: needs_revisionneeds_review

I pushed bug30573_9.0_02 for 9.0. The difference between this branch and the 8.5 branch are avoiding a race between loading the tab and the Gecko profile loading, and correcting a bug caused by incorrectly checking if sanitizing is enabled.

comment:15 Changed 4 months ago by gk

Keywords: TorBrowserTeam201907R added; TorBrowserTeam201907 removed

comment:16 Changed 3 months ago by gk

Keywords: TorBrowserTeam201907R removed
Status: needs_reviewneeds_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? 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).

comment:17 in reply to:  16 Changed 3 months ago by sysrqb

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

Note: See TracTickets for help on using tickets.