130307 - cached compose window interacts poorly with multiple desktops

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Mike Shaver (:shaver emeritus)]

(At first, I thought mail compose was broken in 0.9.9 because of this.  I'm much
calmer now!)

No matter which desktop I'm on when I press Ctrl-M or click Compose or click a
mailto: link, the cached compose window always appears where I first used it,
desktop-wise.  Subsequent Ctrl-Ms bring up windows where I expect them.

Cc:ing blizzard for window manager guidance.

Comment 1

[Jean-Francois Ducarroz]

all we should do is to reposition the compose window before showing it up,
should be simple to do. How can I figure out where a new window should go? on a
single screen/desktop, it always appears at the same position and size than the
previous one.

Comment 2

[Christopher Blizzard (:blizzard)]

There are some gnome hints which might help here that might work with some
window managers, and most modern ones.  However, there isn't going to be a
solution which works all places.

Havoc, is there a gnome hint that allows you to move a window to the current
desktop window?

Comment 3

[Mike Shaver (:shaver emeritus)]

If we just move it to (coords-of-window-that-triggered-compose + 50x50) or
something, will that work?  Can we get those coords?

Comment 4

[Jean-Francois Ducarroz]

can I know at least on which desktop I am? if yes, I can attach a cached window
to a specific destop, like we do currently with composition mode (plaintext or
html).

Comment 5

[Christopher Blizzard (:blizzard)]

Desktops don't use absolute coordinates.  So, +50+50 is +50+50 on the desktop
that the window is located.

Comment 6

[Havoc Pennington]

My take on this is that it's a window manager bug. If Mozilla is withdrawing the
toplevel (gtk_window_hide()) and then showing it again, then on reshow 
the window should be handled as if it were a new window, i.e. appear on the
current desktop, etc. If it isn't handled this way then the window manager is
just broken and should be fixed, Mozilla shouldn't try to work around it.

Also note that some window managers have crackrock "features" that would have
this effect, like putting all windows with a certain class on the same desktop, 
or trying to session manage apps that are not session managed. ("Remember window
positions" is what Sawfish calls this broken option I think.)

Comment 7

[Mike Shaver (:shaver emeritus)]

Hrm.

So does that mean that "create at +50+50" and "move to +50+50" will result in
different window placement, if the latter move takes place after a desktop
switch?  Ick.

Comment 8

[Christopher Blizzard (:blizzard)]

No, it doesn't.  It means that it will be at +50+50 on the desktop that it's
located.  You can't switch the desktop of a window by changing it's coordinates.

Comment 9

[Christopher Blizzard (:blizzard)]

Hey, I never did test this.  The compose window always comes up on my current
desktop, no matter where it was last placed.  So it might just be your window
manager, Mike.

Comment 10

[Mike Shaver (:shaver emeritus)]

: shaver; rpm -q sawfish
sawfish-0.38-ximian.5

Ah well.  Feel free to close WFM, jfd.

Comment 11

[Christopher Blizzard (:blizzard)]

Works for me.

[blizzard@dead blizzard]$ rpm -q sawfish
sawfish-0.38-11

Comment 12

[Jean-Francois Ducarroz]

I tested with Linux 7.0 using gnome and kde. The compose window always open on
the current destop!

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

verified (per Shaver's comment).  Stone me if I've misinterpreted.