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

[Tor Bug Tracker & Wiki]

#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:
 https://www.youtube.com/watch?v=TQxuuFTgz7M

 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
 ideas?

 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