Database window not mapped after reopen

[pniemann]

When reopening the database (that is, from the lockedDialog Dialog) the database window is not mapped at all on my desktop.

I have Debian GNU/Linux with X11 and fvwm2 and two monitors using xinerama.

Password Gorilla is at version 1.5.3.7-1 as packaged with debian jessie.

When I open a new instance of password gorilla from the command line and enter the database password, I get the database window mapped as expected (I currently use manual placement style in fvwm). After staying idle for some time the database gets auto-locked and the lockedDialog window gets mapped as expected (again manual placement).

But the next time I enter the password the database window is not mapped at all. It doesn't appear in the window list of fvwm, it is not visible anywhere on my desktop, just seems to crash. But the process is not crashed and after some time the database gets auto-locked. At that time the lockedDialog is mapped again as expected.

I have tried some tweaking with fvwm styles but to no success yet.

I didn't have this kind of problem with debian wheezy. Downgrading to that version (1.5.3.4-1 with bwidget instead of tklib) resolves the issue.

Kind regards, Philipp

[rich123]

Interesting... (and not in a good way).

I also run Fvwm2 and so far I have never seen this issue myself. Would you be willing to try a couple of tests to see if we can narrow down a potential culprit?

First test. In your home directory, PasswordGorilla will have created a file .gorillarc which stores saved settings (including sizes/positions of windows so they can be remapped at the same location). Try renaming your existing .gorillarc to another name and testing again. My first suspicion is that the saved positions are such that when remapping the DB window, it is actually very far off screen in one direction.

If the above does not help, would you be willing to try a quick test temporarily without xinerama. My second suspision is that something with xinerama is interacting badly with Tk and causing the issue. If this turns out to be a cause then some more investigation will likely be needed to work out how to get it to behave when run with xinerama.

[pniemann]

Re,

On Wed, 27.05.2015-14:32:47 -0700, rich123 wrote:

I also run Fvwm2 and so far I have never seen this issue myself. Would you be willing to try a couple of tests to see if we can narrow down a potential culprit?

you're quite welcome.

First test. [snip] Try renaming your existing .gorillarc to another name and testing again.

I did that but the window still is not visible after unlocking.

If the above does not help, would you be willing to try a quick test temporarily without xinerama. My second suspision is that something with xinerama is interacting badly with Tk and causing the issue. If this turns out to be a cause then some more investigation will likely be needed to work out how to get it to behave when run with xinerama.

I am currently using password-gorilla with vncserver and have the same issue. I am pretty sure vnc doesn't have xinerama (it should be listed in the output of xdpyinfo, shouldn't it?).

I did change the fvwm mapping behavior. With the FvwmConsole Module I have changed the Style for "Gorilla*":

Style "Gorilla*" GNOMEIgnoreHints, WindowListHit, ManualPlacement

After that, I get the window mapped as expected. But only once. If I lock the database and want to reopen it, the database window is again not mapped at all.

This is repeatable. After issuing the FvwmConsole Command again, the window is once more mapped as expected. One time.

Bye, Philipp

[rich123]

Two additional items to try.

1) What would be the set of FVWM stylings your .fvwm2rc applies to Gorilla by default. I can try applying those locally myself to see if one or the combination triggers the bug locally for me (which if they do will help tremendously in fixing the issue);

2) Since you are running Debian, the .deb install package should have installed the Gorilla source code. Would you be willing to try making a quick edit to your gorilla.tcl file to output some debugging information, which might at the very least indicate what is happening when it appears to disappear from the screen?

If yes, then find the location where your gorilla.tcl is installed and do the following (the edit steps you'll need to do as a user with write permissions, this will usually be 'root'):

1) Make a backup copy of gorilla.tcl;

2) Open gorilla.tcl in a text editor, and search for a line that begins: "proc gorilla::LockDirtyMessage";

3) About 30 lines up lower line numbers) you should find another line that reads: "# restore all closed window statuses and positions"

4) The next line after #3 above should begin "foreach tl", and the next line after that should begin "wm state". Insert a new blank line between the "foreach" and "wm state" lines and add this text to the new blank line:

puts stderr "$tl $withdrawn($tl)"

5) Now, open a terminal (xterm/rxvt/etc.) and from the terminal window, launch gorilla.tcl (you should be able to type just "gorilla.tcl" (without quotes) to launch it, if not you might have to type the full path to the executable, i.e. /usr/bin/gorilla.tcl)

6) Cause the issue to happen, after which you should see some extra text output to the terminal window by gorilla.tcl. Copy and pasted that extra output here into another reply.

7) Undo your changes (if you wish to undo them at this point) by replacing the edited gorilla.tcl with the backup you made in step #1 above.

[pniemann]

Hi again,

On Fri, 29.05.2015-04:55:40 -0700, rich123 wrote:

Two additional items to try.

1) What would be the set of FVWM stylings your .fvwm2rc applies to Gorilla by default. I can try applying those locally myself to see if one or the combination triggers the bug locally for me (which if they do will help tremendously in fixing the issue);

this is not too easy to answer. I have a directory ~/.fvwm/ with a split up config. If I understand fvwm config correctly, it should be

Style "" IconBox 120x340+0-0 Style "" ForeColor grey40 Style "" BackColor #11236b Style "" SmartPlacement Style "" RandomPlacement Style "" SlipperyIcon Style "" IconBox +40 +350 -0 -0, \ Style "" BorderWidth 2, HandleWidth 2 Style "" NoPPosition Style "" NakedTransient Style "" Layer 0 0 Style "Password Gorilla" GNOMEIgnoreHints, WindowListHit Style "Gorilla.tcl" GNOMEIgnoreHints, WindowListHit Style "lockedDialog" GNOMEIgnoreHints, WindowListHit, !UsePPosition

2) Since you are running Debian, the .deb install package should have installed the Gorilla source code. Would you be willing to try making a quick edit to your gorilla.tcl file to output some debugging information, which might at the very least indicate what is happening when it appears to disappear from the screen?

I did the change you suggested. This is the output I get:

. normal 640x480+27+243 . iconic 640x480+27+243 . iconic 640x480+116+232

I did some testing to make sure the issue is fvwm related. Without any window manager, the problem is gone. twm maps the gorilla window as expected, too. Back to fvwm and the mapping is broken.

Philipp

[rich123]

The output from the puts command is interesting. It seems to show three "." window names, which should be impossible in Tk. Can you add that one back, and add another line immediately below the the line containing this string: "# close all open windows and remember their status and location":

puts stderr "Locking: [array get ::gorilla::toplevel]"

Then recreate the bug and post the new output.

Also, after you try that, about eight lines down is a line that reads: "wm withdraw $tl". Change the word "withdraw" to "iconify" and then try to recreate the bug. Note, no need to post the testing output for the "iconify" vs "withdraw" test. This one is I want to see if changing the window state Gorilla uses to "hide" windows makes the bug go away.

[pniemann]

Hi,

On Fri, 29.05.2015-09:04:22 -0700, rich123 wrote:

The output from the puts command is interesting. It seems to show three "." window names, which should be impossible in Tk.

I have posted the output of unlocking the database thrice.

Can you add that one back, and add another line immediately below the the line containing this string: "# close all open windows and remember their status and location":

puts stderr "Locking: [array get ::gorilla::toplevel]"

Then recreate the bug and post the new output.

This is the ouput I get when locking the database for the first time after program start:

Locking: .openDialog .openDialog . .

Icon is displayed. After unlocking:

. normal 640x480+0+0

No window is mapped. After the idle timeout the database gets locked:

Locking: .lockedDialog .lockedDialog .openDialog .openDialog . .

No Icon is displayed. Again I unlock the database:

. iconic 640x480+0+0

The database window is mapped as expected. I lock the database:

Locking: .lockedDialog .lockedDialog .openDialog .openDialog . .

The Icon is displayed. After unlocking:

. normal 640x480+292+144

No window is mapped.

Also, after you try that, about eight lines down is a line that reads: "wm withdraw $tl". Change the word "withdraw" to "iconify" and then try to recreate the bug. Note, no need to post the testing output for the "iconify" vs "withdraw" test. This one is I want to see if changing the window state Gorilla uses to "hide" windows makes the bug go away.

Please be aware that I applied this change before the output posted above was generated.

Bye, Philipp

[rich123]

Sorry for the long delay, but real life intruded.

So, if I read you correctly, even when changing to 'iconify' instead of 'withdraw' you still get the window disappearing, correct?

What happens on your system if, from a terminal window, you type "wish" to open a blank Tk window, and then type the following at the % prompt:

wm withdraw . wm deiconify .

On my system, if I do the above, without moving the blank "wish" window from where it first opens, it will appear and disappear in the same spot on the screen. However, if I move it somewhere else and repeat, it will pop back to where it first opened when I typed "wish".

[pniemann]

Hi and thanks for your reply.

On Sat, 22.08.2015-14:52:59 -0700, rich123 wrote:

So, if I read you correctly, even when changing to 'iconify' instead of 'withdraw' you still get the window disappearing, correct?

Yes, the window is disappearing. But only every other time. I verified this again today.

This is different from the unchanged gorilla.tcl. With the unchanged version, I don't get a mapped window regardless of how many retries I make.

What happens on your system if, from a terminal window, you type "wish" to open a blank Tk window, and then type the following at the % prompt:

wm withdraw . wm deiconify .

On my system, if I do the above, without moving the blank "wish" window from where it first opens, it will appear and disappear in the same spot on the screen. However, if I move it somewhere else and repeat, it will pop back to where it first opened when I typed "wish".

I have the same behaviour on my system.

Regards, Philipp