[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 arma):

 Replying to [comment:3 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.

 It seems like rather than resetting to 0%, tor launcher should ask tor
 what its current bootstrap progress is, and then use that for starters.
 That is, the simple bug here is that Tor Launcher puts the progress bar
 back to 0, and then waits for Tor to tell it a new progress number, yet
 Tor will only emit an event when it's made further progress beyond what it
 told you about in the last event.

 So yes, Tor Launcher should either remember the current level of progress,
 or if it wants to be stateless (maybe that's more elegant?), do a getinfo
 to fetch it whenever you're going to reset the progress bar.

 > 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

 Agreed, but then you need to update it to the amount of progress that Tor
 thinks it has told you it's made. Tor doesn't know that you reset the
 progress bar, so it can't know that it needs to send you another
 (redundant, from its perspective) bootstrap event.

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

 That's a great question. I will let the network team decide on their
 future answer, but as for what the code does right now, bootstrap_percent
 never moves backwards, and Tor tries to avoid emitting any bootstrap
 progress events unless the new number is bigger than the number from the
 last event.

 (Should Tor Launcher be doing the getinfo anyway, on startup, in case it
 missed a few bootstrap events before it connected to the control port?)

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

 I agree. (But I am open to being overruled by Linda et al if they can help
 us do better. :)

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