Hi there.
I have strange behavior of Openbox WM after upgrading from 3.4 to 3.5 on Gentoo Linux.
It randomly happens, that some of new windows, that should be placed on top upon creation, are created in background.
I've tried to investigate it to have more details, but the only thing I have discovered is that:
1) windows randomly don't get focused when launching them from within other applications, Nautilus context menu OR by pressing xbindkeys hotkey
2) windows always get properly focused when launching from Gnome menu or "Application launcher" placed on Gnome Panel.
I have recorded this for a demonstration. It is available here: http://chaosonline.pl/openbox_focus_problem_demo/
This is the most frustrating when working fast, when there is no time to check if window get properly focused or not.
Comment 1Douglas A. Augusto
2013-10-22 01:37:35 EDT
Hi,
I am also experiencing this bug since Openbox 3.5.0 (currently I am using Openbox 3.5.2). This report seems to be related to bug 5419
Yes, sounds the same as 5419 to me. I have this too in 3.5.2-8, debian testing/sid. Very annoying. Not sure if I have much more helpful info to offer other than what has already been covered, but I would like to help this get fixed.
People are also talking about it at launchpad: https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808
As they point out in #5419, this seems to be specific to a circumstance where the application you're starting already has a window open elsewhere. I also would add, that if the currently focused window is another window of the same program you are opening, then focus always works correctly, for me at least.
Bug 5419 is talking about Iceweasel. I experience it with Iceweasel and with xfce4-terminal, at least. Others at launchpad mention gnome-terminal and Thunar. Someone at launchpad claims it *doesn't* happen with lxterminal.
Someone mentioned that it seemed like if you click the desktop at any point, that triggers it to begin happening, and then it may stop happening after you click a bunch of windows.
For me, I haven't tested yet whether or not it happens *before* I ever once click on the desktop, but I have noticed it does seem to start and stop in some very obscure -- one might indeed say "random" -- situations.
No single thing seems to clearly trigger one behavior or the other, that I can figure out. I currently am experiencing the following (doing everything via keybind except closing windows):
- desktop 1, iceweasel maximized and a few xfce4-terminals behind it
- desktop 2, empty
- i open new iceweasel on desktop 1, focuses normally
- i open new xfce4-terminal on desktop 1, focuses normally
- i open new iceweasel on top of this, focuses normally
- i close the extra windows, change to desktop 2, open xfce4-terminal, then open iceweasel - iceweasel doesn't focus or raise
- i close the extra windows, go back to desktop 1, repeat steps, proper normal behavoir again
- i close the extra windows and start typing up this behavior for you, go to try testing again, suddenly new xfce4-terminal won't focus anymore, stays beneath iceweasel
- i go to desktop 2, open xfce4-terminal, open iceweasel - iceweasel focuses and raises properly!
- i get exasperated and start intensely messing around with trying different ways of reproducing
That's about where I am now. I am noticing that it seems to *maybe* make a differencee HOW I CLOSE my windows: the window "x" decoration, ALT+F4, or CTRL+D for terminals. Maybe that has to do with where my mouse is clicking, or something, but I still can't seem to reproduce proper and improper behavior consistently enough to tell.
If someone thinks it would help, I can try making a real solid study of this, recording each action from the moment I run startx, so as to get something reproducible.
For now I will wait, as I'm not sure if maybe someone already has ideas of how to fix. For example, at launchpad the maintainter seems to think there is a fix already lying somewhere long forgotten in the Openbox git:
https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808/comments/9
I don't have the coding knowledge so I can only listen.
Anyway I think that ended up not being too helpful for how long it was. But at least we have that info here if it ever becomes useful. Hope to help out with this further if I can.
> For now I will wait, as I'm not sure if maybe someone already has
> ideas of how to fix. For example, at launchpad the maintainter
> seems to think there is a fix already lying somewhere long forgotten
> in the Openbox git:
> https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808/comments/9
> I don't have the coding knowledge so I can only listen.
Hm.
% git branch --contains 3b9fce92e0afab89a46080f525e4392bc4c01aa5
returns nothing. I'm not sure how they even found this commit or where it went..
Created attachment 3499[details]
Results of some obsessive but scatter-brained testing
Okay I just basically went to an empty desktop and pressed nothing but the buttons:
- keybind for iceweasel
- keybind for xfce4-terminal
- ALT+F4
in various sequences. I spent quite a long time, as you can see from my attached log of the results, I got a little obsessive.
Here is the only real useful information I got out of it:
A. I seem to be able to trigger misbehavior (failing to raise or focus a newly created window) consistently by doing the following:
1 keybind for Application A twice (open 2 windows)
2 ALT+F4 once
3 keybind for Application B once
Application B consistently spawns behind Application A. This seems quite robust in that it has now worked many times outside of the simple circumstances I was using. However, I do believe that I observed this failing to produce misbehavior once, which is confusing.
B. This does NOT seem to account for all instances of misbehavior, though I could be wrong.
I noticed many other things, but there was nothing else that I could reliably reproduce, and since I'm already being wordy I won't overburden this post.
Anyway I hope this might help.
Okay new info:
1. I reproduce bug by:
have 1 iceweasel open, no other windows anywhere
ctrl-alt-right (go to empty desktop)
super+t (open xfce4-term window)
super+t (open xfce4-term window)
alt+f4 (close one xfce4-term window)
super+w (open iceweasel window)
Iceweasel does not raise or get focus, the xfce4-terminal window stays on top.
2. If I:
have 1 iceweasel open, no other windows anywhere
ctrl-alt-right (go to empty desktop)
super+w (open iceweasel window)
super+w (open iceweasel window)
alt+f4 (close one iceweasel window)
super+t (open xfce4-terminal window)
Xfce4-terminal raises and gets focus properly.
3. But if I:
have 1 iceweasel open, 1 xfce4-terminal open, no other windows
ctrl-alt-right (go to empty desktop)
super+w (open iceweasel window)
super+w (open iceweasel window)
alt+f4 (close one iceweasel window)
super+t (open xfce4-terminal window)
Xfce4-terminal does not raise or get focus, the iceweasel window stays on top.
So far too lazy to try closing my iceweasel :D
This so far mostly just confirms what they said in Bug 5419, that this only occurs when one window of the application is already open somewhere.
**BUT** I noticed something else: in 1 and 3, there seems to be a difference based on *how long I wait* after pressing ALT+F4, before opening the new window. If I go *very slowly*, I never seem to see the bug. If I go *very quickly*, I always or almost always see the bug.
Seems like that may be very helpful for debugging, if it's correct.
Okay don't quote me on that. Rather, say: I do not know why, but if I:
have 1 iceweasel open, no other windows anywhere
ctrl-alt-right (go to empty desktop)
super+t (open xfce4-term window)
super+t (open xfce4-term window)
alt+f4 (close one xfce4-term window)
super+w (open iceweasel window)
Sometimes the iceweasel window raises and gets the focus, sometimes not. It is either completely random, or based somehow on the speed/timing of my keystrokes.
> For now I will wait, as I'm not sure if maybe someone already has > ideas of how to fix. For example, at launchpad the maintainter > seems to think there is a fix already lying somewhere long forgotten > in the Openbox git: > https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808/comments/9 > I don't have the coding knowledge so I can only listen. Hm. % git branch --contains 3b9fce92e0afab89a46080f525e4392bc4c01aa5 returns nothing. I'm not sure how they even found this commit or where it went..
Created attachment 3499 [details] Results of some obsessive but scatter-brained testing Okay I just basically went to an empty desktop and pressed nothing but the buttons: - keybind for iceweasel - keybind for xfce4-terminal - ALT+F4 in various sequences. I spent quite a long time, as you can see from my attached log of the results, I got a little obsessive. Here is the only real useful information I got out of it: A. I seem to be able to trigger misbehavior (failing to raise or focus a newly created window) consistently by doing the following: 1 keybind for Application A twice (open 2 windows) 2 ALT+F4 once 3 keybind for Application B once Application B consistently spawns behind Application A. This seems quite robust in that it has now worked many times outside of the simple circumstances I was using. However, I do believe that I observed this failing to produce misbehavior once, which is confusing. B. This does NOT seem to account for all instances of misbehavior, though I could be wrong. I noticed many other things, but there was nothing else that I could reliably reproduce, and since I'm already being wordy I won't overburden this post. Anyway I hope this might help.