[tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
---------------------------+------------------------------------
 Reporter:  catalyst       |          Owner:
     Type:  defect         |         Status:  new
 Priority:  High           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+------------------------------------

Comment (by mcs):

 Replying to [comment:2 dcf]:
 > I was one of the people who helped with the study. As I understand it,
 the problem has more to do with Tor Launcher than with tor. I don't think
 the problem has to do with cached directory information. Rather, it is
 that Tor Launcher resets the state of the progress bar to 0% every time
 the progress screen is displayed, even though the tor process's (hidden)
 percentage is greater than 0%.

 Indeed, this is what Tor Launcher does. When we wrote the code, we assumed
 that progress would occur reasonably quickly when things were going to
 work (which means that tor would send another bootstrap status message to
 Tor Launcher soon, so starting at zero would not matter much). If instead
 there is a long wait before the next bootstrap status message, things will
 not look good to the user.

 > Imagine you start bootstrapping and watch the progress bar get to 60%,
 then you get impatient and hit Cancel. (tor is in fact still bootstrapping
 in the background even though the GUI doesn't reflect that.)

 We tried to address that in #11879 by changing Tor Launcher to do `SETCONF
 DisableNetwork=1` when the user cancels. But note related tickets #15713
 and #15715.


 > You fiddle with the configuration and try to bootstrap again. At this
 point, the progress bar misleadingly shows 0%, even though the tor process
 is still at 60%. Now, as soon as tor makes a little more progress (say to
 65%), the progress bar will immediately update itself to the new value,
 giving the effect of a jump from 0% to 65% when it should have been from
 60% to 65%. What users found misleading was the progress bar going back to
 0% after they changed the configuration; even though in reality the
 percentage hadn't changed or had even increased, they assumed that their
 configuration changes had caused bootstrapping to make negative progress.

 Based on your description, it seems like this behavior violates most
 people's "mental model" of what is happening underneath the covers. I
 think it would be okay to reset the progress to zero if progress was then
 made at a rate similar to when the previous configuration settings were
 used (to the user, this is an "everything starts from scratch" model). Or
 picking up where things left off, e.g., at 60%, would also be okay with
 most users, although if there is a lengthy stall there they may still give
 up. Finer-grained progress reporting would help.

 > I thought that the solution would be to have Tor Launcher either cache
 its last seen progress percentage, so it can reinitialize the progress bar
 properly, or else have some background listener that tracks the percentage
 status even when the progress bar is not actually on screen.

 Here is a question for the Network Team: would it be safe for Tor Launcher
 to cache the progress value? Will things ever move backward? I don't think
 adding caching to Tor Launcher would be difficult at all, and Tor Launcher
 is monitoring the bootstrap status events even when its progress window is
 not open so in theory it could always know the current progress value.

 > > When bootstrapping with existing directory information, we should
 rescale the progress numbers so they advance on something resembling a
 linear time scale, which is probably closer to what users expect to see.
 >
 > Does that mean that if bootstrapping got to 60%, was cancelled, and then
 restarted, that the progress bar would visually reset back to 0%, but that
 the remaining 40% would be stretched to fit a 0–100 scale? E.g. 60%→0%,
 70%→25%, 80%→50%, 90%→75%, 100%→100%?

 I have to say that I don't much like they idea of "rescaling" the
 progress. I think it would be better to promote a model to the user that
 lets them know that half way across means the same thing every time, in
 every copy of Tor Browser, whether it is their own browser or that of a
 friend they are trying to help.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22266#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online