Opened 5 months ago

Last modified 4 months ago

#27476 new defect

Remove gap between Tor Launcher window and main browser window

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tor-launcher tbb-performance ux-team
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Right now, the Tor Launcher runs, and takes seconds or minutes to complete. The Tor Launcher window, though it says "Tor Browser" on the first screen is not recognizably a web browser, which may be confusing or scary to first-time users.

Then the Tor Launcher window disappears, and then, before a browser window appears, there is a gap of varying length where no window is visible at all. On slow computers, this gap can be as much as tens of seconds and during that time there is no easy way to tell that Tor Browser is still running.

Often users, mistakenly guessing that Tor Browser has crashed, will double-click the Tor Browser app icon a second time and get messages like "Tor Browser is already running, but is not responding" or "Tor unexpectedly exited".

How can we solve this problem? I can think of a few possible solutions:

  1. Don't hide the Tor Launcher window until the main browser window is visible. (Build the browser window hidden during the launch process so that it can appear fast as soon as the launch process is done.)
  2. Show the main browser window below the Tor Launcher window while it launching process is running. Keep the Tor Launcher window modal (always on top) until it is finished.
  3. Embed the Tor Launcher UI in the main browser window. Allow the user to enter a URL in the URL bar even before Tor is fully launched.

I favor (3) as having the best UX. But it is also the most difficult to implement.

Child Tickets

Change History (7)

comment:1 Changed 5 months ago by arthuredelstein

Summary: Show main browser window alongside Tor Launcher UIRemove gap between Tor Launcher window and main browser window

comment:2 Changed 5 months ago by cypherpunks3

Arthur did you forget about "early first blank paint" bugzilla ticket that you did comment on? :)

IMO that's like the best way to solve this issue, drawing a blank white window right after the Torlauncher window closes is the perfect way to cope with perceived slowness, since it's cheaper to paint and will solve the issues that are pointed out above.

comment:3 in reply to:  2 ; Changed 5 months ago by arthuredelstein

Replying to cypherpunks3:

Arthur did you forget about "early first blank paint" bugzilla ticket that you did comment on? :)

IMO that's like the best way to solve this issue, drawing a blank white window right after the Torlauncher window closes is the perfect way to cope with perceived slowness, since it's cheaper to paint and will solve the issues that are pointed out above.

I don't think users will necessarily understand what a blank window means.

Without looking at the code or testing further, my guess is a big part of the perceived slowness is due to real slowness, which is that we delay starting to build the browser window until after the launch process is finished.

comment:4 in reply to:  3 ; Changed 5 months ago by cypherpunks3

Replying to arthuredelstein:

I don't think users will necessarily understand what a blank window means.

Well it would at least solve the issue you eloquently describe in paragraph 2 & 3, right?

Without looking at the code or testing further, my guess is a big part of the perceived slowness is due to real slowness, which is that we delay starting to build the browser window until after the launch process is finished.

Right, that can be fixed too.

(Note: For the alphas on Linux who have SelfRando the content processes are slow to load so it's very noticeable, especially on an Intel Atom. There's a ticket for that.)

Last edited 5 months ago by cypherpunks3 (previous) (diff)

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

Replying to cypherpunks3:

Replying to arthuredelstein:

I don't think users will necessarily understand what a blank window means.

Well it would at least solve the issue you eloquently describe in paragraph 2 & 3, right?

Yes, it would help! And I appreciate the suggestion. But I think a blank window would be confusing and so, I'd prefer to keep the Tor Launcher window open instead if we go with Option 1.

comment:6 Changed 5 months ago by traumschule

Doesn't TB ship the user-manual? Why not open it while waiting for the bootstrapping to finish?

comment:7 in reply to:  6 Changed 4 months ago by mcs

Replying to traumschule:

Doesn't TB ship the user-manual? Why not open it while waiting for the bootstrapping to finish?

No, the manual is not bundled (although we have talked about that idea in the past).

It might be worthwhile for someone to investigate why it takes 10-20 seconds for the browser window to open. Does that same delay occur when starting Firefox 60 ESR? If there is nothing that can be done about that delay, option 1 above (keep the Tor Launcher window open until the browser window opens) seems like the safest and lowest cost option.

Note: See TracTickets for help on using tickets.