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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 mikeperry):

 Replying to [comment:19 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.

 This is the difference. On Linux+Gnome desktop, if I hold the mouse button
 down and stop dragging like you did in the video, the grey margin does not
 disappear, nor does the outer window actually resize if I release the
 button without a further drag movement. The window remains stuck at the
 held size with the grey margins without a resize. This is why I added the
 return value after the check for the deltas in shrinkWrap(), and the
 subsequent invocation of ping() inside the timeout handler.

 On my system, Firefox thinks that the gBrowser's parent element *was*
 resized, but it also thinks the window element's outerWidth and
 outerHeight were not resized. Unfortunately, the window outer sizes also
 contain the toolbar and the title bar heights, and so the resize keeps
 happening as if there were still a discrepency, no matter what. Hence my
 suggestion that we try to find an element that is not actually resized, or
 figure out some other way to infer this information (perhaps by computing
 the size of these elements?)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14429#comment:20>
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