Positioning and occasional sizing issues on LXDE (Linux) with Smart All

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install on a dual-monitor (Xinerama or TwinView, side-by-side) LXDE desktop 
with the panel spanning the entire bottom of the desktop.
2. Set "Smart All" and multi-monitor mode
3. Cycle between maximized and restored at least once

What is the expected output? What do you see instead?
It should behave normally. Instead:
- It may produce an un-decorated window in a different position with the same 
dimensions rather than maximizing
- It's most likely to set appropriate dimensions for maximization... and then 
move the window so the top [titlebar_height] pixels are off the top of the 
screen, leaving a [titlebar_height] pixel gap of uncovered desktop below.

What version of the product are you using? On what operating system?
Hide Caption Titlebar Plus (Smart) 1.1.2 on Firefox 3.6.3 on Gentoo Linux with 
an LXDE 0.5.0 desktop which uses OpenBox 3.4.11.1 as the window manager.

LXPanel has been configured so the default panel spans the full width of the 
desktop.

Also, in case it helps, this machine has two 1280x1024 monitors side-by-side 
and hooked into an nVidia card using the binary drivers with TwinView, 
producing a 2560x1024 desktop.

Please provide any additional information below.

I'm not familiar with Firefox's API, so I'm not entirely sure how it behaves in 
a case like this (I'm more familiar with using GTK+ directly) but I get the 
feeling this might be an order of operations issue.

Original issue reported on code.google.com by stephan....@gmail.com on 24 Jun 2010 at 1:38

[GoogleCodeExporter]

Hi
Last version 2.10 have fixes and improved compatibility in multi-monitor 
handling. Now you have more options for this. Please give it a try.
I don;t have that linux desktop to try. Perhaps latest fixes solves the issue.

FYI: Fx3.6 needs a special maximized mode when titlebar is hidden.  Upcoming 
Fx4 instead don't need this and it's working very well in all scenarios 
tested.! :-)

tks for reporting!

Original comment by redlibr...@gmail.com on 20 Nov 2010 at 2:10

• Changed state: Started

[GoogleCodeExporter]

Finally got around to testing it (Biiig mess-up in my course scheduling), but 
it seems to still be a problem.

Once I managed to turn off all the new features that just annoyed me (and the 
"new Firefox 4 menu" option since I'm used to my Compact Menu 2 toolbar button 
and don't like my menu reliably appearing on the wrong monitor), I found that 
the problem I experienced before is the one problem which remains.

Maximizing now reliably sizes it to be a pixel or two too short to cover the 
desktop completely and then moves it so that, if my monitor is 1280x1024 and 
the titlebar is 20 pixels tall and the taskbar is 22 pixels tall, the window's 
geometry will be something like:

top: -20px
left: 0
width: 1024px
height: 1256px (roughly. Basically, a pixel or two too short to cover the 
desktop when relocated into place)

Couldn't you just offer an option which just shows the internal min/max/close 
buttons, asks for the window to be undecorated and maximized, and lets the 
window manager do the rest? The whole point of HAVING a window manager is to 
keep each and every app from providing its own buggy window management system.

I'm seriously considering just looking up how to script my WM to ignore all 
sizing/positioning requests by Firefox non-dialog windows and changing the 
"Win+M" maximize keybinding to "maximize and undecorate"... of course, with my 
luck, your extension will react to the refusal to comply by refusing to show 
the buttons.

Original comment by stephan....@gmail.com on 25 Dec 2010 at 2:26