When using Tor for private tabs, need UI changes that take Tor process startup time into account

[davidtemkin]

Test Plan

1. Open a Tor private tab, ensure the connection info is shown in URL while Tor connection is being established.

Description

While the Tor process is starting up, the browser should not permit a user to browse to a URL via Tor in a private tab. There should be (a) a visual indicator that shows something is happening, and (b) the UI should either make it impossible to enter a URL in this state -or- allow the URL to be entered, but only attempt loading once the Tor process is up and running and ready to receive requests. It should be impossible to get the proxy error.

Steps to Reproduce

1. Create a new private tab and enable private browsing via Tor
2. While Tor is being initialized, attempt to browse to a URL

Actual result:
If you navigate to the URL before the Tor process is ready, an error message results: "Could not create a connection to the proxy server. An error occurred either in resolving its name, or in connecting a socket to it. Note that this does NOT include failures during the actual "CONNECT" method of an HTTP proxy."

Expected result:
No error message should occur. The user should not be able to navigate until the Tor process is ready; and a clear visual/UI state should block this navigation.

Reproduces how often:
Anytime you get ahead of Tor process launch.

Brave Version

about:brave info:
0.23.2

Reproducible on current live release:
no

[diracdeltas]

there's at least 3 non-UI bugs here:

1. the tor process doesn't ever start on linux because the executable isn't marked as executable (fixed in 297afb2)
2. the tor process should start at startup instead of first tab launched (to-be-fixed in muon, partly done in browser-laptop cb9be30)
3. the tor process seems more flakey than it should be on mac and windows. both @davidtemkin and @lukemulks reports that it seemed to never connect even after waiting a long time.

^ fixing these will reduce the likelihood that a user encounters the 'cannot connect' error page

once tor init is moved to startup, we could do the following:

1. when user opens a private tab with Tor currently disabled, the Tor switch is shown greyed out if Tor is not done initializing (instead it shows "not yet initialized...") so the user can't enable it until it is done initializing
2. if Tor is currently enabled but Tor is not done initializing, the private tab says "Tor is not initialized..." and a warning sign saying that the user will not be able to browse unless they turn it to off. If they then try to navigate, the navigation is blocked.

[diracdeltas]

@bradleyrichter since Tor has been moved to startup, I estimate that in 95%+ of cases that Tor will either be fully initialized by the time the first private tab is opened or be unable to initialize at all. So if we added a progress indicator, it would either show 0 or 100 the vast majority of the time. May be easier to just show "Initializing..." , "Tor is unable to start", or "Tor is running"

[tildelowengrimm]

@davidtemkin, @diracdeltas, @bradleyrichter, @riastradh-brave, & I talked it over.

When Brave starts, it spawns a Tor process. Based on a static timeout (10-30s?) or the presence of error messages in Tor's logs, Brave may conclude that the Tor process is in one of three possible states:

• starting
• running successfully
• failed to start

When a user opens a new private tab, the behavior depends on the Tor process' state, and the Tor toggle state / action

toggle	starting	running	failed
off	0	0	0
on	load	1	load*
→ on	load	1	load*

In case 0: the new tab page is displayed with the Tor toggle off. User browses as normal.

In case 1: the new tab page is displayed with the Tor toggle on. User browses as normal, using Tor.

In the load case: Brave displays the text "Connecting to the Tor network…" in the URL bar while a loading indicator in the background of the URL bar sweeps from left to right over whatever 10-30s timeout is in use*. The user cannot click or enter text in the URL bar while this occurs.

Eventually, the attempt to connect to Tor either succeeds or fails. On success, the URL bar is returned to normal. On a failure, a JS OK/Cancel modal is shown with the following text:

Unable to connect to the Tor network. Click okay to disable Tor or cancel if you plan to try again later.

*If Tor has already failed to load, the "loading" animation should take only a second or two before moving to the failure JS modal.

Additionally, if the Tor process is in the failed state, toggling the Tor setting on (or off and then on) should cause the Tor process to be killed and then restarted. This requires Muon support in brave/muon#591 .

@bradleyrichter will provide mock-ups.

[riastradh-brave]

Here's what the back end in #14146 provides:

1. A callback for notification of progress in startup ('bootstrap percent').
2. A callback for when tor is now known to be functioning ('circuit established').
3. A callback for when tor is now known to be not functioning ('circuit not established').

States 2 and 3 may alternate if your internet connection dies, of course. This should correspond to the UI discussed above, with the additional possibility that tor may go from functioning to not functioning, so 'tor is not functioning' is not, strictly speaking, 'tor was unable to start' since it was once able to start.

[petemill]

@flamsmark @bradleyrichter So we are blocking the URL being changed whilst Tor is still progressing towards a functioning state? What about the Stop icon - I assume we're still allowing that, at which point the url bar becomes active? Or are we blocking all navigation actions until Tor is established?
@bradleyrichter do you have that mockup yet?

[tildelowengrimm]

I don't think I understand the question about the stop button — no page is being loaded, there's nothing to stop. The goal is to prevent attempts at navigation while Tor isn't ready, and to provide visual feedback that something is in progress.

[petemill]

Ah ok @flamsmark I missed the fact that the UI will be blocked before a url is entered, not after. Hopefully this will work the same with non-url bar mechanisms (e.g. 'Open Link in new Private Tab').

[tildelowengrimm]

Yes, that's the more challenging case. It should be less visible in that scenario, and the behavior can probably be the same?

[alexwykoff]

@rossmoody if you could review the UX changes here, that would be great.

[riastradh-brave]

We merged #14395 tonight!

[btlechowski]

Verified on Ubuntu 17.10 x64

• 0.23.17 - bc754eb
• Muon - 7.1.2
• libchromiumcontent - 67.0.3396.87

Verified with macOS 10.12.6 using

• 0.23.17 bc754eb
• Muon 7.1.2
• libchromiumcontent 67.0.3396.87