Tor Browser window does not get resized to the same sizes as before 6.5a4 anymore

After switching to 6.5a4 I noticed that my Tor Browser window's height is less than it was before 6.5a4. In both cases it was/is rounded properly though. Thus, it seems that the new code is not really using the available space as it could. This happens on a Linux box (Debian testing) with XFCE.

added TorBrowserTeam201704 component::applications/tor browser ff52-esr-will-have owner::tbb-team priority::high resolution::fixed severity::major status::closed tbb-6.5-regression tbb-fingerprinting-resolution tbb-usability type::defect labels

Trac:
Keywords: tbb-fingerprinting-resize deleted, tbb-fingerprinting-resolution added

Also Gentoo XFCE after upgrading to 6.5a5. The default new window size changed from 1000x1000 px to 1000x900 px.

Trac:
Keywords: N/A deleted, tbb-6.5-regression added

it was/is rounded properly So, not a fingerprinting issue. code is not really using the available space as it could. The available space could be seen in debug log during startup, e.g.:

Torbutton INFO: Initializing the Torbutton button.
Torbutton INFO: init completed
Torbutton INFO: Window: (132,38) ?= (1920,1160)
Torbutton DBUG: Window is normal

for 1920x1200 monitor. So, if you have 1080p monitor you should check how much space is available after XFCE takes some. And if it takes more than 80px (<1000 available), then it's not a bug.

Trac:
Keywords: tbb-usability, tbb-fingerprinting-resolution deleted, N/A added
Status: new to needs_information

Trac:
Keywords: N/A deleted, tbb-usability, tbb-fingerprinting-resolution added

Taking this as the bug for investigating reduced screen sizes due to our Firefox patch. A user reports getting a new window size of 800x600 while they had 1000x600 before: https://blog.torproject.org/blog/tor-browser-65-released#comment-232732.

Arthur, can you take a look at it?

Trac:
Keywords: N/A deleted, TorBrowserTeam201701 added

Trac:
Severity: Normal to Major
Priority: Medium to High

#21333 (moved) is a duplicate.

Trac:
Status: needs_information to assigned
Cc: arthuredelstein to arthuredelstein, amd64

Similarly 1000x500 instead of 1000x600 on Windows 7

Moving our tickets to Feb 2017.

Trac:
Keywords: TorBrowserTeam201701 deleted, TorBrowserTeam201702 added

Replying to cypherpunks:

Also Gentoo XFCE after upgrading to 6.5a5. The default new window size changed from 1000x1000 px to 1000x900 px.

I have an update to this. I have two displays with different resolutions. The lower resolution (1600x1050) display was considered primary by the OS. I ran Tor Browser on the higher resolution display (1920x1200). Today I unplugged the smaller display and the Tor Browser window went back to normal size 1000x1000. It's like TBB was initially resizing the window based on the primary (lower resolution) display size, instead of which desktop the window was opened on.

Here's my fix. There are three patches. The first just uses the full available pixels on screen instead of 95%. The second updates debugging code. And the third fixes Firefox's GTK code so that outerWidth/outerHeight takes the entire window into account, including system decorations.

https://github.com/arthuredelstein/tor-browser/commits/20905+2

Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201702 deleted, TorBrowserTeam201702R added

I've built Linux bundles (and am currently building for other platforms as well) and tested the 64bit version on my Linux box. I get the attached screen shot on first start (note: the window width is even larger than the one of my monitor) and the following error in my terminal

*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: can't access dead object
Full stack: this.PromiseWalker.completePromise@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:700:9](/gre/modules/Promise-backend.js:700:9)
TaskImpl_run@re[/gre/modules/Task.jsm:320:13](/gre/modules/Task.jsm:320:13)
Handler.prototype.process@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:933:23](/gre/modules/Promise-backend.js:933:23)
this.PromiseWalker.walkerLoop@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:812:7](/gre/modules/Promise-backend.js:812:7)
this.PromiseWalker.scheduleWalkerLoop/<@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:746:1](/gre/modules/Promise-backend.js:746:1)

*************************

Let me know what you need from me to track this issue down.

Trac:
Keywords: TorBrowserTeam201702R deleted, TorBrowserTeam201702 added
Status: needs_review to needs_revision

Trac:

Moving tickets to March

Trac:
Keywords: TorBrowserTeam201702 deleted, TorBrowserTeam201703 added

Remmove remaining tickets over to April

Trac:
Keywords: TorBrowserTeam201703 deleted, TorBrowserTeam201704 added

This seems to be fixed for me with the switch to ESR52. Please reopen if that is not the case on other machines/systems. This will make it into 7.0a3.

Trac:
Keywords: N/A deleted, ff52-esr-will-have added
Resolution: N/A to fixed
Status: needs_revision to closed

This is fully fixed on Windows and Mac, but may still occasionally be noticeable on Linux, depending on the screen size and the size of toolbars, etc. Unfortunately a true fix for Linux is tricky because GTK is unable to report the height of a window's title bar before it is shown on screen. I opened #21945 (moved) to keep this problem in mind.