Opened 2 years ago

Last modified 6 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: intrigeri Actual Points:
Parent ID: #31283 Points:
Reviewer: Sponsor: Sponsor30

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 (14)

comment:1 Changed 2 years ago by arthuredelstein

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

comment:2 Changed 2 years 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 2 years 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 2 years 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 2 years ago by cypherpunks3 (previous) (diff)

comment:5 in reply to:  4 Changed 2 years 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 2 years 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 2 years 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.

comment:8 Changed 15 months ago by pili

Should this be closed now that tor launcher is integrated into tor browser?

comment:9 Changed 15 months ago by acat

The integration in #28044 should not change the behaviour of current tor-launcher, so in slow computers I assume this gap between Tor Launcher window and main browser window might still be noticeable.

I guess something similar to arthur's third suggestion

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.

is something that could be implemented in the future to solve this (#31286 can be seen as a first step I think). But not completely sure on the UX plans for that, and did not find a ticket for that either (but there might be).

comment:10 Changed 14 months ago by intrigeri

Cc: intrigeri added

comment:11 Changed 9 months ago by antonela

Parent ID: #31283

comment:12 Changed 7 months ago by antonela

Sponsor: Sponsor30

comment:13 Changed 6 months ago by Thorin

I'll piggyback on this ticket

https://blog.torproject.org/comment/287619#comment-287619

STOP BLINDING US BY POPPING OUT A HUGE WHITE WINDOW WHILE CONNECTING TO TOR!!! GO BACK TO THE OLD WAY... FIRST YOU CONNECT TO TOR. THEN OPEN A NORMAL LOOKING PURPLE COLORED WINDOW.

TAKE WHITE WINDOW BACK!!!

I notice this with AFAICT 100% reliability on non en-US builds (on windows). I currently have 31 non en-US alphas here (all set to spoof english: but I doubt that makes a difference). It does not happen on en-US builds. So there's definitely something going on with languages.

FYI: setting browser.startup.blankWindow = false (default true) fixes this: but I don't know if that will introduce more problems vs fixing something cosmetic. +1 for Arthur's 3rd proposal

comment:14 in reply to:  13 Changed 6 months ago by gk

Replying to Thorin:

I'll piggyback on this ticket

https://blog.torproject.org/comment/287619#comment-287619

STOP BLINDING US BY POPPING OUT A HUGE WHITE WINDOW WHILE CONNECTING TO TOR!!! GO BACK TO THE OLD WAY... FIRST YOU CONNECT TO TOR. THEN OPEN A NORMAL LOOKING PURPLE COLORED WINDOW.

TAKE WHITE WINDOW BACK!!!

I notice this with AFAICT 100% reliability on non en-US builds (on windows). I currently have 31 non en-US alphas here (all set to spoof english: but I doubt that makes a difference). It does not happen on en-US builds. So there's definitely something going on with languages.

FYI: setting browser.startup.blankWindow = false (default true) fixes this: but I don't know if that will introduce more problems vs fixing something cosmetic. +1 for Arthur's 3rd proposal

#32728 is your friend.

Note: See TracTickets for help on using tickets.