maximized window gets resized with Tor enabled

Hi, when I maximize (with my window manager) firefox, here is what I get: http://img503.imageshack.us/img503/8113/screenshotnontorxw6.png

but when I maximize it with tor enabled, here is what I get: http://img68.imageshack.us/img68/8116/screenshottorbk3.png

You can see that the bottom of the window does not appear. It looks like window's height is too big. I've never experienced that behaviour before.

[Automatically added by flyspray2trac: Operating System: All]

Trac:
Username: arno

added MikePerryIteration20110630 actualpoints::1 component::torbrowserbutton points::3 priority::very high reporter::arno resolution::duplicate status::closed type::defect version::1.1 labels

I found it is because tor resizes window to a multiple of 50px. I if disable corresponding preference, that behaviour disappears.

I think that bug is invalid.

Trac:
Username: arno

Actually I misunderstood. I actually coded the feature to check window.windowState and NOT operate on either minimized or maximized windows. Firefox is incorrectly reporting window.windowState for maximized windows here.

We should file a firefox bug..

Firefox correctly reports when window is maximized. Problem occurs when window is fullscreen, which is a different state. I opened a mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=445696

Trac:
Username: arno

I've made an attempt at a workaround for this. I can't reproduce it exactly on my machine, but maybe this will get it. Can you try the snapshot in the attachments tab by running:

firefox -jsconsole

from a command line and then paste me the output? It should print out a bunch of Torbutton NOTE level messages (loglevel 4) about resizing the window.

Trac:
torbutton-1.2.0-dev.xpi.11

Torbutton with attempt at fullscreen detection

r1eo| did anybody knows that torbutton returns non rounded screen.height for maximized window, with all that individual toolbars and icon size crap it's can be very unique without rounding. I guess it's already some bug number? Sebastian| people had complained that their browser window was resized when they were maximizing their browser Sebastian| I think mikeperry might be unaware of the toolbar and icon size stuff you just mentioned. Sebastian| Shall I file a bug report for you? r1eo| it's a bad feature :) r1eo| people loodly complains, I think it needed look at this at least.

Trac:
Milestone: N/A to N/A
Priority: minor to normal
Description: Hi, when I maximize (with my window manager) firefox, here is what I get: http://img503.imageshack.us/img503/8113/screenshotnontorxw6.png

but when I maximize it with tor enabled, here is what I get: http://img68.imageshack.us/img68/8116/screenshottorbk3.png

You can see that the bottom of the window does not appear. It looks like window's height is too big. I've never experienced that behaviour before.

[Automatically added by flyspray2trac: Operating System: All]

to

Hi, when I maximize (with my window manager) firefox, here is what I get: http://img503.imageshack.us/img503/8113/screenshotnontorxw6.png

but when I maximize it with tor enabled, here is what I get: http://img68.imageshack.us/img68/8116/screenshottorbk3.png

You can see that the bottom of the window does not appear. It looks like window's height is too big. I've never experienced that behaviour before.

[Automatically added by flyspray2trac: Operating System: All]
Keywords: N/A deleted, N/A added

Firefox claims this bug is now fixed upstream. Let's try implementing a detection mechanism. There's also a huge dup chain. Here are some other relevant bug numbers: https://bugzilla.mozilla.org/show_bug.cgi?id=510546 https://bugzilla.mozilla.org/show_bug.cgi?id=484488

Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A
Parent: N/A to N/A
Priority: normal to critical

Trac:
Component: Torbutton to TorBrowserButton

If Firefox really fixed the root cause, this should be easy. I bet it's not though... Plus fixing it will require me using some crazy window manager like ratpoison..

Trac:
Points: N/A to 3
Keywords: N/A deleted, MikePerryIteration20110612 added

Trac:
Keywords: MikePerryIteration20110612 deleted, MikePerryIteration20110630 added

I'm pretty sure the remaning cases of this are due only to #3506 (closed).

Trac:
Actualpoints: N/A to 1
Resolution: None to duplicate
Status: new to closed

closed

changed time estimate to 24h

added 8h of time spent

mentioned in issue #750 (closed)

mentioned in issue #1393 (closed)