[tbb-bugs] #14429 [Tor Browser]: Automated rounding of content window dimensions

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Feb 13 06:46:34 UTC 2015

#14429: Automated rounding of content window dimensions
     Reporter:           |      Owner:  tbb-team
  arthuredelstein        |     Status:  needs_review
         Type:  defect   |  Milestone:
     Priority:  normal   |    Version:
    Component:  Tor      |   Keywords:  tbb-fingerprinting-resolution, tbb-
  Browser                |  torbutton, TorBrowserTeam201502R
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |

Comment (by arthuredelstein):

 Replying to [comment:16 mikeperry]:
 > What made you pick 1000ms? If we set this to 100ms or even 10ms, will
 there be issues on some systems? I will play with some timeouts on my
 systems and see if I notice anything, but I was curious if you had a
 reason for picking such a large delay.

 That's a good point. While the user is resizing the window (by dragging an
 edge or corner), the chrome window object fires many "resize" events. I
 couldn't find any nice way to detect if the user has stopped dragging the
 window (mousedown/up events don't fire), so I decided just to wait until
 it we feel it is safe to assume that the user has finished dragging before
 calling `shrinkwrap()`. I'm not sure what this time is, but 250 ms seemed
 too short, at least with myself as the test subject. I think 500 ms seems
 OK. (If the user does pause in a drag, then the shrinkwrap occurs anyway,
 even though the mouse is still in "dragging" mode.) Let me know what you

 I just measured the typical time interval between "resize" events and the
 interval is almost always 50 ms or less, except if I leave the mouse down
 and stop moving for a while. (This may be unusually easy for me because I
 am testing with a touchpad where a double-tap leaves the mouse down.)

 > I think there may also be a race/timer resolution issue with the ping()
 function. In one instance, my window was not resized. I'm not sure, but I
 suspect this may be because the '''if (now - lastPingTime >= timeout)'''
 check failed due to the timer actually firing slightly early.

 Weird. Seems like the timer firing early should be considered a bug. In
 any case, I've written a new version of that patch with a simpler and
 hopefully more robust pinger function and I've reduced the timeout to 500


 > Also as a general matter, I'm not sure we actually need the grey border
 and the content window quantization for drag-based resizing, but only for
 maximization or other window manager enforced sizing. In other words, it
 seems fine to reveal the intermediate sizes to the content window if the
 user is simply dragging, but it is not fine to reveal the intermediate
 size if the window manager was maximizing or tiling the window. I guess it
 may not be possible to tell the difference in practice, though?

 Yes, I couldn't find a way to tell immediately that the user has clicked
 the maximize button. In my observations, the "sizemodechange" event only
 occurs after maximization has completed, and it is preceded by a number of
 "resize" events. For window tiling, I'm not sure we would get any special

 > My statements about trying to not display the grey border during drag
 hinge on how bad we think it is to keep reflowing as if we would allow the
 resize, only to snap back to a size the user wasn't expecting. Maybe I'm
 wrong, and it is actually better to give the user a hint with the grey

 I do like having some sort of hint what the final window size is going to
 look like. But I may be the only one...

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

More information about the tbb-bugs mailing list