[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs