#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs