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:  arthuredelstein
  arthuredelstein        |     Status:  needs_revision
         Type:  defect   |  Milestone:
     Priority:  normal   |    Version:
    Component:  Tor      |   Keywords:  tbb-fingerprinting-resolution, tbb-
  Browser                |  torbutton, tbb-4.5-alpha,
   Resolution:           |  TorBrowserTeam201503R, GeorgKoppen201503R
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:34 gk]:
 > I have so far 3-4 issues to report all on a normal Windows 7 box:
 >
 > 1) I get (after maximizing) 1586X700 back (no DPI messing involved just
 the default 100% is used).

 My guess is this was caused by a failure of the
 gBrowser.contentWindow.innerWidth to update properly, which I have
 observed occasionally. Momentarily increasing gBrowser.width by 1 seems to
 fix this.

 > 2) If I play with my DPI value (a lot of complains about the current
 resize code running during start-up are related due to non-default DPI
 values) and increase the size of text etc. to 150% and start Tor Browser,
 I can see how the resizing is step-wise ongoing until my height is only
 100 and the browser is basically not usable for me. I end up with
 DPI_issue1.png which is attached.

 DPI seems to cause some weird rounding errors when we call
 window.resizeTo(...). The shrinking window overshoots and causes the
 content window to further shrink, which causes the window to shrink more,
 etc. So I added 2-pixel margin of safety so that the window can't
 overshoot.

 > 3)
 > a) If I enlarge the text etc. to 125%, I start with 1000x500 which is
 good but maximizing leads sometimes to 1200x400

 Same solution as (2).

 > b) If a) is the case and I drag the window out to the left it gets
 resized to 600x500 (which is okay). But if I maximize the window now, I am
 left with 1200x499 (which happens as well after resizing if a) is not
 happening).

 I hope this is fixed by the same trick in (1).

 I have also made some improvements which gets zoomed windows to behave
 correctly (occasionally inner width/height are off by 1, such as 199
 instead of 200, which has to do with rounding error by Firefox, and
 doesn't seem to be fixable).

 I did a number of tests on Windows at multiple DPIs, and it seems to be in
 better shape. I also tested on OS X, and Ubuntu with Gnome, and KDE. (An
 extra fix was introduced to get KDE to work properly.) As far as I can
 tell, the response to the user resizing or maximizing the Window works
 consistently in all OSs.

 One new problem I ran into, is that when I rebased my patch on top of the
 latest master, I found that the new anti-maximizing notice from #7225
 actually changes the content window inner width/height! I'm not sure what
 the best way to deal with this is.

 Here's my patch. In testing it may be useful to set torbutton loglevel to
 3, to see the window innerWidth/Height in real time as you resize/maximize
 the window.

 https://github.com/arthuredelstein/torbutton/commit/1295a13778b9b46d0a819b8ad5cfc355b1a16332

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