awesome

Welcome to awesome bug tracking system.
Tasklist

FS#692 - Icedove binds to tag on the wrong screen

Attached to Project: awesome
Opened by Michael Barkowski (AKBS) - Friday, 04 December 2009, 14:56 GMT
Task Type Bug Report
Category Core
Status Unconfirmed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.4.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No

Details

When I start Icedove on for example the right screen, the message/main window and the biff icon both displays on the right screen, but it is bound to the current tag on the left screen, instead of the current tag on the right screen, tag 9 for example.

(My hypothesis is that Icedove is special because it has a systray icon.)

No matter what tag I have selected on the right screen, the visibility of the icedove (thunderbird) window is wholly dependent on whether tag 9 on the left screen is selected.

I see no other problems.

Not sure which Category this should fall under.

I am running Debian testing, with X.org 7.4, using the non-free nvidia-kernel display driver with TwinView providing two screens.

Running awesome 3.4.2 on debian.
The only modification to the source is:
--- awesome-3.4.orig/awesomerc.lua.in
+++ awesome-3.4/awesomerc.lua.in
@@ -7,6 +7,9 @@
-- Notification library
require("naughty")

+-- Load Debian menu entries
+require("debian.menu")
+
-- {{{ Variable definitions
-- Themes define colours, icons, and wallpapers
beautiful.init("@AWESOME_THEMES_PATH@/default/theme.lua")
@@ -60,6 +63,7 @@
}

mymainmenu = awful.menu({ items = { { "awesome", myawesomemenu, beautiful.awesome_icon },
+ { "Debian", debian.menu.Debian_menu.Debian },
{ "open terminal", terminal }
}
})
This task depends upon

Comment by Michael Barkowski (AKBS) - Friday, 04 December 2009, 15:02 GMT
Not so sure about that hypothesis. I uninstalled the package providing the tray icon, but the problem remains.
Comment by Michael Barkowski (AKBS) - Friday, 04 December 2009, 15:11 GMT
Aha! there is a workaround. Once you maximize with Mod4 + m (Mod4 bound to Windows key on my keyboard), Icedove jumps over to the screen on which the tag is bound.
Comment by Michael Barkowski (AKBS) - Friday, 04 December 2009, 15:14 GMT
Note that the problem exists whether you run under Gnome by choosing Gnome from gdm menu and running sudo killall -9 -r metacity && awesome to switch to awesome, or whether you simply choose awesome from the gdm menu.
Comment by Julien Danjou (jd) - Friday, 04 December 2009, 16:27 GMT
It's more than probable that it starts with it top left corner on the other screen.
Comment by matt seburn (mattca) - Thursday, 17 December 2009, 16:00 GMT
I'm seeing the same behaviour with firefox...
Comment by Uli Schlachter (psychon) - Monday, 15 March 2010, 10:56 GMT
Can anyone confirm that the window's top-left corner is on the other screen? (This corner is what counts)
Comment by Javier Barroso (i5513) - Monday, 15 March 2010, 17:10 GMT
Hi,

In my environment, I have 2 screens, and the next rc.lua config (only Icedove to tag [2][2]).

When I start icedove with autoconfig setup (from awesome commandline), it works (in sid version).

When it is launched from autostart configuration: two auth windows (asking me user and password to imap and caldav) are in tag[2][2]), but main windows is in the second screen and tag 1, but without any "focus" it appears at all tags in second screen.

The "selector" (the area where you can click and take the focus in the bar on the top) is in screen 1 (sorry for my english)

$ diff -u /etc/xdg/awesome/rc.lua ~/.config/awesome/rc.lua
--- /etc/xdg/awesome/rc.lua 2010-01-19 14:24:38.000000000 +0100
+++ /home/javi/.config/awesome/rc.lua 2010-03-15 17:26:11.000000000 +0100
@@ -300,6 +300,8 @@
properties = { floating = true } },
{ rule = { class = "gimp" },
properties = { floating = true } },
+ { rule = { class = "Icedove" },
+ properties = { tag = tags[2][2] } },
-- Set Firefox to always map on tags number 2 of screen 1.
-- { rule = { class = "Firefox" },
-- properties = { tag = tags[1][2] } },
@@ -336,3 +338,33 @@
client.add_signal("focus", function(c) c.border_color = beautiful.border_focus end)
client.add_signal("unfocus", function(c) c.border_color = beautiful.border_normal end)
-- }}}
+--
+
+-- Autostart
+function autostart(dir)
+ if not dir then
+ do return nil end
+ end
+ local fd = io.popen("ls -1 -F " .. dir)
+ if not fd then
+ do return nil end
+ end
+ for file in fd:lines() do
+ local c= string.sub(file,-1) -- last char
+ if c=='*' then -- executables
+ executable = string.sub( file, 1,-2 )
+ print("Awesome Autostart: Executing: " .. executable)
+ -- os.execute(dir .. "/" .. executable .. " &") -- launch in bg
+ awful.util.spawn(dir .. "/" .. executable)
+ elseif c=='@' then -- symbolic links
+ print("Awesome Autostart: Not handling symbolic links: " .. file)
+ else
+ print ("Awesome Autostart: Skipping file " .. file .. " not executable.")
+ end
+ end
+ io.close(fd)
+end
+
+autostart_dir = os.getenv("HOME") .. "/.config/awesome/autostart-icedove"
+autostart(autostart_dir)
+

$ cat ~/.config/awesome/autostart-icedove/icedove
if ! ps -C icedove
then
icedove
fi

Thank you very much
I hope this help
Comment by Michael Barkowski (AKBS) - Thursday, 15 April 2010, 16:13 GMT
More info:

I usually only see this the first time Icedove is started in a session.
Once I also saw it happen with Conkeror.

"Can anyone confirm that the window's top-left corner is on the other screen? (This corner is what counts)"
Yes - the entire window is either on one screen or the other, I can confirm that for you, it's quite easy for me to see on the grey background.

To go through the sequence of how to repeat the problem more clearly:

1. I place my mouse in the right screen.
2. Hit Mod-r and type "icedove" to start icedove
3. icedove starts. It is maximized (showing a bird icon in the title bar). The window is on the right screen, the title bar is on the left screen.
4. As soon as I un-maximize it with Mod-m, the window jumps over to the left screen to be with the title bar.
5. I can now Mod-drag the window back to the right screen, and after that everything behaves as normal. I can even close and restart icedove.

Latest version I have demonstrated this on in debian, using the default /etc/xdg/awesome/rc.lua:
awesome 3.4.4-1

~$ awesome --version
awesome v3.4.4 (Jet Sex)
• Build: Mar 9 2010 11:39:21 for i686 by gcc version 4.4.3 (@murphy)
• D-Bus support: ?
Comment by Michael Barkowski (AKBS) - Thursday, 15 April 2010, 16:30 GMT
Another potentially useful discovery:

I can now make this happen _at will_ to any of icedove (a.k.a thunderbird), iceweasel (a.k.a firefox) or conkeror (mozilla-based browser with emacs-like interface).

The trick is, it depends on whether the application was maximized when it was last closed.

So try this:

1. Run firefox
2. Maximize it
3. Quit it
4. Run firefox again and you should see the problem.

If instead firefox is not maximized when it is closed, the problem will not appear the next time firefox is started.
Comment by anrxc (anrxc) - Thursday, 15 April 2010, 18:07 GMT Comment by Michael Barkowski (AKBS) - Thursday, 15 April 2010, 18:21 GMT
Ah - I see - it seems this is a known issue. Glad to see there is a workaround.

I cannot find an existing bug for this.

Perhaps we can rename this bug: "Clients maximized in their previous invocation behave weird".
Comment by Michael Barkowski (AKBS) - Thursday, 15 April 2010, 18:25 GMT
Unfortunately the workaround doesn't appear to have any effect.
Comment by Uli Schlachter (psychon) - Thursday, 15 April 2010, 18:57 GMT
If this indeed happens across client restarts, then it has to be something with client hints.

Can one of you run "xprop" in a terminal, click on a faulty window (that is, after the restart) and paste the result?
Comment by Michael Barkowski (AKBS) - Monday, 26 April 2010, 14:14 GMT
Here's the xprop outputs:

Log out of X and back in
Start icedove on right screen (title appears on left screen)
take xprop capture (xprop-icedove.txt)
Un-maximize icedove (jumps to left screen)
Mod-drag icedove back to right screen
take second xprop capture (xprop-icedove-2.txt)
Comment by Javier Barroso (i5513) - Thursday, 14 October 2010, 06:54 GMT
Currently I fixed this issue, at least when autostart is configured to run iceweasel/icedove, adding this script to autostart dir:
cat ~/.config/awesome/autostart/01mousemove
xdotool mousemove_relative -- -100 0

I discover that:

If I don't touch the mouse while awesome is configured to 'autostart' iceweasel and it (awesome) is starting, the follow behaviour happen:

1. Mouse cursor is in first screen
2. While iceweasel start mouse cursor changes to second screen (without any human interaction)
3. Window selector of iceweasel appears in first screen (when I have configured it to appear in second screen)
4. iceweasel window appear in second screen (this is correct, but 3 not)

If I move in the beggining of awesome start the cursor mouse to the left (first screen), then all work fine
If I move in the beggining of awesome start the cursor mouse to the right (second screen), then it works like I described from 1 to 4 steps

So If I run xdotool like the first program to move cursor to the left, it works

I hope my bad english won't confuse you

Thanks!
Comment by Jean-Luc Duflot (jihell78) - Monday, 26 December 2011, 07:12 GMT
Hello,

I just configured awesome with a second monitor :
-monitor1 : 19" 1280x1024
- monitor2 : 17" 1024x768
-virtual screen 2590x1024, same systay in both monitors.
-I had to configure xorg with "Option "Primary" for monitor1.

I have the same behaviour with icedove (starting maximized automatically on monitor1 with awesome) : opening a menu displays it on the upper left corner of monitor2 ; mod4-M twice then opening the menu makes it displaying normally on monitor1.

Iceweasel, Libreofice work normally.

My config : debian wheezy, awesome v3.4.11, icedove 3.1.16
Comment by Uli Schlachter (psychon) - Friday, 10 January 2014, 16:24 GMT
 FS#1204  is a duplicate of this

Loading...