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

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Feb 14 06:14:32 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:18 mikeperry]:
 > Ok, I think you are right that we should leave the grey border in there
 as a hint to the user about what we're going to do to the window size.
 > I think also I understand why I was able to get the window to fail to
 resize now. I simply held on to the resize drag too long.

 I think maybe we are seeing different behaviors for some reason. In the
 latest version of my patch, after quite a bit of testing I haven't
 observed a resize failure (on OS X). Here's a recording of a few tests:

 One relatively minor issue shown at the end of the movie is that, when I
 hold the mouse button down during a resize drag, but I stop moving the
 mouse, after a timeout I see `shrinkwrap` runs, meaning the window shrinks
 so that there is no grey margin around the gBrowser (web content) element.
 Then, if I move the mouse a little, holding the mouse button down, the
 window border jumps back to follow my mouse cursor again. It's an odd
 looking behavior, but I don't see how to avoid it without hacking on
 Firefox. In any case, whenever I finally release the mouse button, the
 timeout expires and `shrinkwrap` runs a final time.

 Most of the time, I hope users will simply drag the window to
 approximately the size they want, and then release the mouse. Then the
 window would resize once, 500 ms later.

 > I played around with trying to reschedule the ping() function if there
 was still discrepency in the gbrowser container vs content window box, but
 I wasn't sure which elements to use for sizing that.

 I'm not sure why you are getting a discrepancy -- on my machine, 500 ms
 after dragging ends, the grey margins invariably disappear.

 > If we can get this idea to work, perhaps we can set the timeout much
 quicker (ie 10ms). I attached a patch that attempts to do this (but leaves
 the timeout as-is, since it was easier to see the log messages arrive in
 the browser console).

 I fear a timeout of 10 ms would be problematic, because then shrinkwrap
 would often be called between "resize" events (which are often 30 ms apart
 during a resize drag).

 > Unfortunately, I tried a few things and couldn't find the right element
 to use to check the actual size discrepancy... perhaps you have some

 Maybe I'm not clear on the size discrepancy you're observing -- can you
 post a screenshot?

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

More information about the tbb-bugs mailing list