Project

General

Profile

unexist.dev

subtle

Assorted tidbits and projects

Bug #242

Recent clients order

Added by david unric over 12 years ago. Updated over 12 years ago.

Status:
Confirmed
Priority:
Urgent
Category:
Bugfix
Target version:
-
Start date:
08/07/2011
Due date:
% Done:

0%

Estimated time:
0.00 h

Description

Hi,

I've found inconsistent results of Subtlext::Client.recent method.

If I switch between clients within a one view, returned Array of recent clients keeps an order where last client is pushed into the head (ie. at 0 index) and remaining are shifted to the right (ie. their index is increased by 1).

However if I switch between clients on different views (within a one screen), order 'sometimes' gets lost:
  • Two xterms on 1st view running irb sessions
    left one> Subtlext::Client.current.win 41943074
    right one> Subtlext::Client.current.win 18874402
  • Firefox on 2nd view, win == 16777340
  1. Left xterm (result of cycling between xterms within one view)
    irb(main):047:0> Subtlext::Client.recent.collect {|c| c.win}
    => [41943074, 18874402, 41943074, 18874402, 41943074]
  2. After switching to 2nd view with Firefox and back
    irb(main):048:0> Subtlext::Client.recent.collect {|c| c.win}
    => [*41943074*, *16777340*, 41943074, 18874402, 41943074]

    Good, order was kept.

  1. Right xterm (result of cycling between xterms within one view)
    irb(main):046:0> Subtlext::Client.recent.collect {|c| c.win}
    => [18874402, 41943074, 18874402, 41943074, 18874402]
  2. After switching to 2nd view with Firefox and back
    irb(main):047:0> Subtlext::Client.recent.collect {|c| c.win}
    => [18874402, 41943074, 18874402, *16777340*, 18874402]

    Bad, order is lost, unexpected behaviour.

Is this a bug or am I missing something there ?

10.png (11.2 KB) 10.png check of recent clients list, Firefox properly placed at index Nr. 1, current xterm at index 0 david unric, 08/07/2011 10:51 PM
07.png (11 KB) 07.png two xterms on "terms" view, focus on the right one david unric, 08/07/2011 10:51 PM
26.png (54.1 KB) 26.png switched to 2nd view "www" with Firefox ("Navigator") david unric, 08/07/2011 10:51 PM
39.png (10.2 KB) 39.png switched back to "terms" view, Firefox got placed at index nr. 3 instead of 1 david unric, 08/07/2011 10:51 PM
58.png (12.8 KB) 58.png exactly the same procedure but from left xterm david unric, 08/07/2011 10:51 PM
04.png (54 KB) 04.png switched to "www" view from focused left xterm on "terms" david unric, 08/07/2011 10:51 PM
subtle.rb (21.9 KB) subtle.rb david unric, 08/08/2011 05:45 PM

History

#1 Updated by Christoph Kappel over 12 years ago

Next time please use instance or window names, just the window ids make it tough to read and to understand.

Actually I have no idea, I just tested this in the current devel and I don't see any inconsistency there.

#2 Updated by david unric over 12 years ago

More explicit example:
  1. I'm in view named "terms", launch two xterms, set left gravity for the first, right for the second.
  2. Set focus on right xterm and run an irb session from within:
    irb(main):008:0> Subtlext::Client.recent.collect {|c| c.instance}
    => ["xterm", "xterm", "xterm", "xterm", "xterm"]
  3. Now I switch to view named "www" and back to "terms" (by ViewSwitch action) and check how result of .recent has changed
    irb(main):009:0> Subtlext::Client.recent.collect {|c| c.instance}
    => ["xterm", "xterm", "xterm", "Navigator", "xterm"]
Wrong order, the returned array should look like:
=> ["xterm", "Navigator", "xterm", "xterm", "xterm"]

The issue manifest only if the focus is on right xterm before switching forth & back to other view.

#3 Updated by Christoph Kappel over 12 years ago

I cannot reproduce that. What version of subtle?

#4 Updated by david unric over 12 years ago

dunric@darkstar:~$ subtle -v
subtle 0.10.2988 - Copyright (c) 2005-2011 Christoph Kappel
Released under the GNU General Public License
Compiled for X11R0 and Ruby 1.9.1

#5 Updated by david unric over 12 years ago

Some screenshots to get issue description even more obvious ...

EDIT: what a coincidence, even attached screenshots placed carefully by each step lost their order
07.png -> 26.png -> 39.png (starting with focus on right xterm)
58.png -> 04.png -> 10.png (starting with focus on left xterm)

#6 Updated by david unric over 12 years ago

I've discovered the issue is caused by multiple re-focusing of a client.

  • Let's have two windows in one view. Left covers 66% of a view, right covers remaining 34%.
  • Focus right window with a keyboard or a mouse. If focused with a keyboard, mouse cursor reappears in the centre of the focused window.
  • Now switch to other view (by keyboard) with only one window covering whole area. Mouse cursor is placed in the centre.
  • Now switch back to the original view (by keyboard). The right (smaller) window gets focus, but then unintentionaly gets focus the left (larger) window and then again back the right. Thus list of recent focused windows is updated 3 times.

You can check it out by implementing client_focus hook with debugging output:

on :client_focus do |c|
  $stderr.puts "=> GOT FOCUS: #{c.instance}" 
  $stderr.puts "=> RECENT: #{Subtlext::Client.recent.collect {|c| c.instance}}" 
end

and monitoring .xsession-errors log with tailf or other way.

I'm suspecting it has something to do with improperly placed mouse cursor causing loss of originaly focused window.

#7 Updated by Christoph Kappel over 12 years ago

As I told you, I cannot reproduce this. There is no improperly placed pointer.

Can you post your config? Did you verify, that this happens with the stock config? Running any layout sublets or sublets that modify the focus history?

#8 Updated by david unric over 12 years ago

Did tried with stock config (see an attachment), no sublets. Still repeatedly reproducible on my computer :(

Installed X server version:

dunric@darkstar:~$ X -version

X.Org X Server 1.9.5
Release Date: 2011-03-17
X Protocol Version 11, Revision 0

#9 Updated by Christoph Kappel over 12 years ago

  • Category set to Bugfix
  • Status changed from Unconfirmed to Confirmed
  • Assignee set to Non member users
  • Target version set to Nu

Ok, I can confirm that now. Tested it just with urxvt's and no problems there. So that just happens with windows that use this odd focus model, going to look into it.

#10 Updated by Christoph Kappel over 12 years ago

  • Target version changed from Nu to 28

#11 Updated by Christoph Kappel over 12 years ago

  • Target version changed from 28 to Xi

#12 Updated by Christoph Kappel over 12 years ago

  • Target version deleted (Xi)

Also available in: Atom PDF