Main Window forgets (X-Windows) properties after unlock

[PorcelainMouse]

The main gorilla window that shows the hierarchical database looses it's window attributes after becoming locked and unlocked. For example, if you set your window to be sticky (aka always-on-visible-window), then it will no longer be sticky after unlocking. I could be wrong, but I think the older version didn't forget attributes.

I figure this is a result of destroying the main window on lock. I guess it would be nice if everything happened in just one window, but I read in other bugs that would require a redesign. But, that's not necessary, anyway. If the main window could somehow have it's attributes restored or not forgotten, that would be nice.

[rich123]

I figure this is a result of destroying the main window on lock.

Except that PWGorilla does not destroy the main window upon lock. It "hides" the windows (wm withdraw 26 lines into gorilla::LockDatabase) and then "unhides" the same, unchanged, windows upon unlock (wm state 161 lines into gorilla::LockDatabase).

For some reason the "withdrawn" state (that produced by "wm withdraw") must be causing your window manager to forget the sticky settings.

Myself, with FVWM2, I just tested a blank wish and FVWM2 remembers dynamically set stickyness through a withdraw/restore operation:

$ wish (now set sticky setting using WM controls - not configured in a config file) % wm withdraw . % wm state . normal

Under FVMW2 the blank wish window goes away, then returns with sticky settings still enabled.

In any case, stickyness is a parameter of one's window manager, and Gorilla has no ability to control the sticky setting even if it wanted to do so.

[PorcelainMouse]

Oh okay. I didn't see it in my window list, so I assumed...wrong.

Thanks for the info about fvwm. I'll report it to my WM developers. On the other hand, it also looks like the standards spec from freedesktop says that the WM "SHOULD" remove window state "hints" when a window is withdrawn. I'm looking forward to a rude response from them.

If that's the case, the only compliant way to achieve this is not to ever withdraw the main window. So, if you ever get to considering the single window redesign, this would be another advantage. But, I admit that sounds like a lot of work. I'll not bother putting that on the wish-list, unless you'd like me to.

That's also interesting information about the sticky parameter. I thought it was just another state flag just like shaded, hidden, maximized, minimized, etc., but NOT iconified, my mistake. They're all listed together in the doc that says they "SHOULD" all be removed on withdraw. I see, however, that Tk's 'wm state' command only has three options, so maybe that's just a Tk thing. (I don't understand the difference between these states and the iconified and withdrawn states.)

Looks like iconify doesn't clear state in my WM. I wonder if I can just search-replace with that? I'll give it a wing and see if I like it.

[PorcelainMouse]

Well, it seems to be working. I replaced most, but not all instances of 'wm withdraw' with 'wm iconify'. I haven't played with it much, yet. Let me know if you'd be interested in that approach. I could send you a patch or something. I'm sure you'd have a better idea if there are unintended consequences.

[rich123]

I'm sure you'd have a better idea if there are unintended consequences.

There is likely one unintended consequence. The definition of an iconified window is different from a withdrawn window. You likely have the ability to deiconify via the WM an iconified window, without interaction with Gorilla's unlock dialog. Which would mean that even though Gorilla is locked, you could still cause to appear the password tree window.

With the current code, you can't interact with the tree in this state, but making this change would introduce at least two issues. One, a security issue in that someone could use the WM deiconify commands to open your locked tree window and see the titles and usernames of the password entries you have stored there. Two, a user interface issue in that someone could have locked PWGorilla, then deiconified the tree view using their WM, and find that the tree does not work, and not realize it is because gorilla is locked. Thereby generating a bug report of a "crashed/stuck" Gorilla when in fact it is just normal locked mode.

Did you try my little simple wish test script? Did your WM also forget the sticky attribute even in that situation? If so, the root cause of the issue is your WM forgetting the setting. Which may be a purposeful choice on the author of the WM's part for sticky settings applied via the mouse to active windows.

Is there any way to configure the WM via a config file to always look for Gorilla and always assign the sticky attribute to the Gorilla window? With FVWM2 I can set sticky via a menu item during use (and which does not persist across restarts), or I can add a line in my .fvwm2rc file that makes sticky permanent (which is actually what I have done for Gorilla and the other items I want to be sticky). Is this config file option available with your WM? If it is, this would likely be the proper way to make the sticky attribute be persistent.

[rich123]

If you look at http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2456788 you will notice that "sticky" is listed as a Non-ICCCM feature. That is why Tk does not have a command to access "stickyness". There is no standard way to access it, as it differs between each WM implementation.

I see the part about removing the properties when windows are withdrawn. That appears to be what your WM is doing. Are you adding the sticky property by selecting a "set sticky" command during runtime, or by a configuration file command stating "all windows of this kind should be sticky"? The runtime command method would go away if one followed this recommendation. But a configuration file command of "all windows of this kind should be sticky" should remain, even across withdraw/remap operations.

In any case, from the wm manpage, it appears that Tk provides only limited script level access to the _NET_WM_STATE operation (normal, iconic, withdrawn), and the sticky attribute is not one of the items that Tk provides any access to at the moment.

I would suggest you look into the config file declaration if you are not already doing that. Because irrespective of what freedesktop.org's doc states, I would argue that a config file directive of "all windows of type X should be sticky" should not be forgotten across a withdraw/remap event of windows of type X.

[PorcelainMouse]

Thanks for all your help and replies, rich. This is clearly a complicated issue.

Yes, I tried the wish script and the behavior is the same as with gorilla: all properties are removed. (I also use 'above'.) In addition, my WM doesn't appear to have any such setting to force attributes on windows. I found the Devil's pie program and it seems to work as designed. I haven't surveyed the WM landscape in a very long time, so perhaps I'll have to do that again.

Thanks again.

[PorcelainMouse]

P.S. In the 1.5.3.5 binary version of gorilla and older versions, too, the timed lock event did not withdraw the window. Though still visible, the main window was "locked." Yes, you can see the hierarchical entries, but you cannot interact with it at all. That's why I didn't consider the security implications you suggested. And yet, the sticky attribute is still removed after unlock. This made me suspect gorilla. I think this was because the window was actually withdrawn and then normalized after unlock. But, I think this has all been changed, because the issue-fixes branch withdraws on both manual and timed lock events.

[rich123]

Yes, I tried the wish script and the behavior is the same as with gorilla: all properties are removed.

This result, as you have likely surmised already, indicates that the source is the WM dropping the properties.

In addition, my WM doesn't appear to have any such setting to force attributes on windows.

What WM are you presently running? Below is the config file setting to apply sticky to Gorilla with FVWM2:

Style "Password Gorilla*" Sticky

I put that into .fvwm2rc, and any windows titled "Password Gorilla*" get the Sticky attribute. I can even do the same with a blank wish window:

$ wish % wm title . "Password Gorilla" (not yet "sticky") % wm withdraw .
% wm state . normal (now "sticky")

I found the Devil's pie

Interesting little program. Any chance you are using the Metacity WM mentioned in the Devil's pie webpage? Because the page points out that Metacity does not have window matching capability. In any case, this does look like a reasonable workaround.

P.S. In the 1.5.3.5 binary version of gorilla and older versions, too, the timed lock event did not withdraw the window.

This I find more interesting. I did not see any changes to the window withdrawing from a quick scan through the diff between 1.5.3.5 and the tip of issue-fixes. Maybe this points to a difference in the starkit executable. I'll have to poke around a bit and see if I can recreate this.

[PorcelainMouse]

I'm using XFCE's WM (xfwm4). I also see references to Devil's pie and wmctrl in association with LXDE (openbox) and other lightweight desktops and even metacity, as you noted and which I wouldn't describe as lightweight. I used fvwm for a long time. I'll include it in my WM review.

I agree with your suspicion regarding starkit. That occurred to me also, but I don't know enough about it to judge the likelihood of that connection. Originally, I was using the static starkit binary with original gorilla source. But, I switched to the single binary when I started using the new github version, thinking that would be more straightforward and fewer things to keep track of on my Flash drive. I think that was a mistake as I would like to be able to run the latest code in the repository.

Thanks again.

[rich123]

I think that was a mistake as I would like to be able to run the latest code in the repository.

Yes, to stay up with the absolute latest changes you'll have to do a bit of your own "packaging" as it were.

If you control all the systems you use your flash drive on, you can install all the necessary Tcl/Tk packages and then you just need the source bundle on your flash drive to run PWGorilla.

However, if you don't control every system (i.e., you can't install things) then you'll need to roll your own kits for your use. The following little bash script is a slightly edited/commented version of what I use to roll up a windows exe for testing purposes:

#!/bin/bash

# edit the two lines below to point at a linux tclkit runtime executable and
# the sdx kit file
kitexe=/path/to/tclkit/executable
sdxkit=/path/to/sdx/kit/file

# edit below to chose what executable runtime to attach to the kit. note,
# this can not be the same executable file as $kitexe, so create a second
# copy and point this at that second copy if wrapping for the same
# architecture as $kitexe

runexe=/path/to/different/tclkit/executable

# should not typically need to edit below this line

sdx="$kitexe $sdxkit"

mkdir temp
cd temp

cp ../gorilla.tcl . 

$sdx qwrap gorilla.tcl
$sdx unwrap gorilla.kit
rm -v gorilla.kit gorilla.tcl

cp -vr ../blowfish/ ../pwsafe/ ../twofish/ gorilla.vfs/lib/
cp -vr ../isaac.tcl ../help.txt ../viewhelp.tcl ../msgs/ ../tcllib/ gorilla.vfs/lib/app-gorilla/

$sdx wrap gorilla.kit 
$sdx wrap gorilla.exe -runtime $runexe

#rm -fr gorilla.vfs/

If you want to go this route, you can turn off the exe creation step (the line containing "-runtime $runexe") and just create a .kit file. Then all you need are the tclkit executables and the .kit file on your flash drive, and you can run PWGorilla on any platform where you can run the tclkit executable itself. You can find the tclkit executables and the sdx utility from the links on the Tclkit page on the Tcl'ers wiki: http://wiki.tcl.tk/52.

Run the script from the toplevel PWGorilla directory (the one where gorilla.tcl resides) and it will create your .kit in a new temp/ directory underneath.

[PorcelainMouse]

Ah! Thanks Rich. I looked into that approach, once, but couldn't figure out how to put all the pieces together. That explains it.

Yes, one of the best things about Gorilla is that, not only is it cross platform, but I don't have spend time to or have the authority to install dependencies on other computers I use. In a pinch, I can use any computer. This has happened before.

[rich123]

You are welcome. Note that the bash script very likely wraps more than the minimum necessary for running PWGorilla. I wrote it to wrap windows test bundles for myself, so I did not care if more came along than was absolutely required. The worst effect however is a slightly larger .kit or .exe file, so no real harm.

I've also got a flash drive with the kit exe's and my password file for exactly the same reasons.

One item to note however, if you ever end up using any "public" setting computers, you are still at the mercy of any/all malware that might have been installed on those systems. PWGorilla can't protect you from malware that sniffs the browser or the clipboard looking for stuff to snatch.