Keeweb: ctrl-t not working properly (Linux/Xubuntu/19.04)

Created on 19 Aug 2019  Â·  53Comments  Â·  Source: keeweb/keeweb

Describe the bug

Pressing ctrl-t hides KeeWeb, but does nothing. As it seems, only when getting back to keeweb, it does actually start with xdotools...as I can guess, because it fills the search with my password.

I cannot tell if it is either:

  • My update to xubuntu 19.04
  • Update to KeeWeb 1.9

To Reproduce

Press ctrl-t

Expected behavior

As before.

Environment

KeeWeb v1.9.0 (64c41785, 2019-08-18)
Environment: electron v6.0.2
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) KeeWeb/1.9.0 Chrome/76.0.3809.110 Electron/6.0.2 Safari/537.36

Logs

As one can see, xdotool only started after 5 seconds or so...

[DEBUG] 2019-08-19T15:12:46.666Z [auto-type] Hide window
[DEBUG] 2019-08-19T15:12:46.772Z [auto-type] Start {USERNAME}{TAB}{PASSWORD}{ENTER}
[DEBUG] 2019-08-19T15:12:46.772Z [auto-type] Parsed [op:USERNAME,op:TAB,op:PASSWORD,op:ENTER]
[DEBUG] 2019-08-19T15:12:46.772Z [auto-type] Resolved [*,key:tab,[,,,,,,,,,,],key:enter]
[INFO ] 2019-08-19T15:12:51.824Z [launcher] spawn xdotool: 0, 5052ms
[INFO ] 2019-08-19T15:12:51.966Z [launcher] spawn xdotool: 0, 142ms
[INFO ] 2019-08-19T15:12:52.048Z [launcher] spawn xdotool: 0, 81ms
[INFO ] 2019-08-19T15:12:52.119Z [launcher] spawn xdotool: 0, 71ms
[INFO ] 2019-08-19T15:12:52.189Z [launcher] spawn xdotool: 0, 70ms
[INFO ] 2019-08-19T15:12:52.260Z [launcher] spawn xdotool: 0, 71ms
[INFO ] 2019-08-19T15:12:52.328Z [launcher] spawn xdotool: 0, 68ms
[INFO ] 2019-08-19T15:12:52.400Z [launcher] spawn xdotool: 0, 71ms
[INFO ] 2019-08-19T15:12:52.469Z [launcher] spawn xdotool: 0, 69ms
[INFO ] 2019-08-19T15:12:52.541Z [launcher] spawn xdotool: 0, 72ms
[INFO ] 2019-08-19T15:12:52.611Z [launcher] spawn xdotool: 0, 70ms
[INFO ] 2019-08-19T15:12:52.680Z [launcher] spawn xdotool: 0, 69ms
[INFO ] 2019-08-19T15:12:52.700Z [launcher] spawn xdotool: 0, 20ms
[DEBUG] 2019-08-19T15:12:52.700Z [auto-type] Complete 5928ms

bug

All 53 comments

Weird, looks like electron waits until the window comes to foreground when spawning a new process from a renderer process. However it seems to be working well from main process. Unexpected, I would say. 😔

Also it seems to be unstable, so I can't confirm it's 100% fixed, however it works for me now. Please let me know if it solves your issue when it's released.

first try works for now! thx for the quick fix!

sorry to reopen. now the auto type feature with alt-shift-t is no more working. I prefer 1.9.0 then :||

it only shows this in logs, when doing alt-shift-t:

[DEBUG] 2019-08-20T08:13:28.024Z [auto-type] Auto type event null
[DEBUG] 2019-08-20T08:13:28.027Z [auto-type] Get window title

Interesting, did it work in 1.9.0? Looks like it’s a different thing.

yes it works in 1.9.0, switched back for now ;_)

On 20.08.19 10:55, antelle wrote:

Interesting, did it work in 1.9.0? Looks like it’s a different thing.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keeweb/keeweb/issues/1234?email_source=notifications&email_token=AADRH6ZFBPMDKNNFPZ6IFUTQFOWP3A5CNFSM4INC23V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VSLRQ#issuecomment-522921414,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADRH64F4EIDKFLJEL6XXA3QFOWP3ANCNFSM4INC23VQ.

does it work for you on 1.9.1 with Linux?

I haven’t tried alt-shift-t on linux, will test it today

I just checked, it's working well for me (in Ubuntu 19 on VirtualBox). What do you see?

on my other computer/laptop, it was broken first (ctrl-t and alt-shift-t) in both 1.9.0 and 1.9.1. but 1.8.2 is working. After installing 1.8.2 (I had 1.8.1), suddenly ctrl-shift-t works but not ctrl-t, even after installing 1.9.0. and in 1.9.1, no ctrl-shift-t, but ctrl-t. so, it's consistent (with my other computer), somehow, at least...

hope you understand this ;-)

does 1.8.2 install something special?

So, do I understand it right that in 1.9.1 ctrl-t works, but alt-shift-t doesn’t (btw, it’s alt, not ctrl). Do you have logs from this laptop?

yes, true. here the logs. first, a ctrl-t, then 3x an alt-shift-t try:

[DEBUG] 2019-08-20T20:00:09.968Z [auto-type] Auto type event {"id":"8184b6fc-074c-9f57-538a-85bfdbbb53f0:bhTvedqIUOIe6H6ErLNjOQ==","uuid":"bhTvedqIUOIe6H6ErLNjOQ=="}
[DEBUG] 2019-08-20T20:00:09.968Z [auto-type] Hide window
[DEBUG] 2019-08-20T20:00:10.078Z [auto-type] Start {USERNAME}{TAB}{PASSWORD}{ENTER}
[DEBUG] 2019-08-20T20:00:10.079Z [auto-type] Parsed [op:USERNAME,op:TAB,op:PASSWORD,op:ENTER]
[DEBUG] 2019-08-20T20:00:10.081Z [auto-type] Resolved [********,key:tab,[*,*,*,*,*,*,*,*,*,*,*],key:enter]
[INFO ] 2019-08-20T20:00:10.320Z [launcher] spawn xdotool: 0, 238ms
[INFO ] 2019-08-20T20:00:10.471Z [launcher] spawn xdotool: 0, 150ms
[INFO ] 2019-08-20T20:00:10.585Z [launcher] spawn xdotool: 0, 114ms
[INFO ] 2019-08-20T20:00:10.693Z [launcher] spawn xdotool: 0, 108ms
[INFO ] 2019-08-20T20:00:10.801Z [launcher] spawn xdotool: 0, 108ms
[INFO ] 2019-08-20T20:00:10.911Z [launcher] spawn xdotool: 0, 109ms
[INFO ] 2019-08-20T20:00:11.018Z [launcher] spawn xdotool: 0, 107ms
[INFO ] 2019-08-20T20:00:11.133Z [launcher] spawn xdotool: 0, 115ms
[INFO ] 2019-08-20T20:00:11.239Z [launcher] spawn xdotool: 0, 107ms
[INFO ] 2019-08-20T20:00:11.352Z [launcher] spawn xdotool: 0, 113ms
[INFO ] 2019-08-20T20:00:11.461Z [launcher] spawn xdotool: 0, 109ms
[INFO ] 2019-08-20T20:00:11.573Z [launcher] spawn xdotool: 0, 112ms
[INFO ] 2019-08-20T20:00:11.638Z [launcher] spawn xdotool: 0, 64ms
[DEBUG] 2019-08-20T20:00:11.638Z [auto-type] Complete 1560ms
[DEBUG] 2019-08-20T20:00:13.401Z [auto-type] Auto type event null
[DEBUG] 2019-08-20T20:00:13.404Z [auto-type] Get window title
[DEBUG] 2019-08-20T20:00:17.039Z [auto-type] Auto type event null
[DEBUG] 2019-08-20T20:00:17.041Z [auto-type] Get window title
[DEBUG] 2019-08-20T20:28:51.520Z [auto-type] Auto type event null
[DEBUG] 2019-08-20T20:28:51.523Z [auto-type] Get window title

KeeWeb v1.9.1 (d16f3356, 2019-08-19)
Environment: electron v6.0.2
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) KeeWeb/1.9.1 Chrome/76.0.3809.110 Electron/6.0.2 Safari/537.36

Interesting, so it can't get the window title, which is also using spawn. I'll try to understand why.

In which state was KeeWeb when you ran auto-type with alt-shift-t?

not being able to get a window title might be because of the new xubuntu release, that introduces some xfce enhancements/upgrades?!

keeweb was as normal, having loaded a kdbx from webdav, and waiting, pw entries list visible. really nothing special.

Most likely it's a combination of both new Ubuntu and new Electron. So, the problem is, we try to start xdotool, however it doesn't start for some reason. Could you please check if xdotool is there in the process list after pressing alt-shift-t?

Would you be able to test beta if I upload a build with more logging and an attempt to fix this?

Looks like xdotool is launched, however it doesn't understand that stdin is closed, even if we call end. I've additionally added destroy and it seems to help. Could you please download 1.9.1 and try beta there (you can switch to beta in settings/general)?

I've tried this. It is not working, logging as before:

```
[DEBUG] 2019-08-22T07:28:42.010Z [auto-type] Auto type event null
[DEBUG] 2019-08-22T07:28:42.012Z [auto-type] Get window title
[INFO ] 2019-08-22T07:28:42.012Z [launcher] spawn:starting
[INFO ] 2019-08-22T07:28:42.053Z [launcher] spawn:waiting

I've had the red "beta" banner, that should be enough, right?

Yes it’s enough. Ok, I’ll try one more thing tonight. It’s weird that such a simple thing as spawn requires so much effort to fix it :(

:(. will check for xdotool in processes, did not see this.

It should be there, waiting for keeweb.

like, after alt-shift-t, checking with ps aux | grep xdotool ?

yes

I cant see xdotool. But. How come it works with 1.9.0? This uses new electron as well, no?

no xdotool in 1.9.1 neither in beta.

1.9.0 is launching xdotool from a renderer process, 1.9.1 from main. Which breaks different things in different places.

I see. Why the change? Or is this not under your control?

I changed it as an attempt to fix the auto-type issue (what you reported), but it broke another thing.

Uploaded a new build to beta, let's try it again please.

sorry, not better. log stays the same.

Quite bad. Not sure what to do with it yet, I'll try to find something in Electron's bugtacker.

By the way, could you please paste logs, what do they say about destroy?

these, nothing special about destroy?
```
[DEBUG] 2019-08-22T18:52:58.287Z [auto-type] Auto type event null
[DEBUG] 2019-08-22T18:52:58.289Z [auto-type] Get window title
[INFO ] 2019-08-22T18:52:58.289Z [launcher] spawn:starting
[INFO ] 2019-08-22T18:52:58.329Z [launcher] spawn:waiting
[DEBUG] 2019-08-22T18:52:59.695Z [auto-type] Auto type event null
[DEBUG] 2019-08-22T18:52:59.698Z [auto-type] Get window title
[INFO ] 2019-08-22T18:52:59.698Z [launcher] spawn:starting
[INFO ] 2019-08-22T18:52:59.738Z [launcher] spawn:waiting

I see, that's because we don't write anything, and we need to apply the same hack in another place as well. Rebuilt the beta, let's try it once more.

sorry, no luck.

and what's there about destroy in logs?

[DEBUG] 2019-08-22T19:09:24.815Z [auto-type] Auto type event null
[DEBUG] 2019-08-22T19:09:24.817Z [auto-type] Get window title
[INFO ] 2019-08-22T19:09:24.818Z [launcher] spawn:starting
[INFO ] 2019-08-22T19:09:24.866Z [launcher] spawn:no-data
[INFO ] 2019-08-22T19:09:24.871Z [launcher] spawn:waiting

Very interesting. I've prepared another patch, let's give it a try.
Sorry for taking so much time, the thing is I can't repeat it on my Ubuntu somehow. Maybe because it's running in VirtualBox and the bug seems to be a random one.

indeed very strange. I'm on xubuntu/xfce, if this makes a difference for electron? guess not, but...

[DEBUG] 2019-08-22T19:18:35.076Z [auto-type] Auto type event null
[DEBUG] 2019-08-22T19:18:35.078Z [auto-type] Get window title
[INFO ] 2019-08-22T19:18:35.078Z [launcher] spawn:starting
[INFO ] 2019-08-22T19:18:35.120Z [launcher] spawn:no-data
[INFO ] 2019-08-22T19:18:35.125Z [launcher] spawn:no-data-destroy
[INFO ] 2019-08-22T19:18:35.130Z [launcher] spawn:waiting
[INFO ] 2019-08-22T19:18:35.130Z [launcher] spawn:no-data-after-write

So, with this in logs, does it work?

sorry, forgot. no, not yet ;-)

Weird, I don't have other ideas yet. I'll try to repeat it on my ubuntu.

...xubuntu introduced some xfce updates in 19.04 (from xfce 4.13). and in 19.10 it will introduce xfce 4.14.

the problem is with launching the program that should get the window title, right?

Yes, for some reason it doesn't get launched.

So, I installed xubuntu-desktop and xfce, and I can repeat it! Looking into the issue now.

Got exactly the same thing as you: either getWindowTitle works, or auto-type. Updated the beta, looks like it's fixed in this version, let's give it a go on your machine.

strike! works. thx man!

Nice, thank you so much for spending your time on this!

It's interesting that both v1.19.0 and v1.19.1 work well on:

  • default Ubuntu
  • Xubuntu / Gnome
  • everywhere else (macOS, Windows)

Well, maybe now it doesn't 😆. I'll dive into virtualboxes to test it and make a release soon if everything is okay.

So I assume, it's not even an issue in Electron, but has something to do with xubuntu-desktop + xfce.

xubuntu uses xfce by default. it's probably a xfce 4.13 problem? I was updating my computers to 19.04, and only after updating, discovered the bug in 1.19.0 (as 1.18.2 was no more working)...maybe it works on 18.04, that has older xfce components (4.12).

lot of versions ;-)

I'm actually not sure whose bug is that. What I see is that a child process is launched, but it doesn't understand that stdin is finished, so it's just waiting for it. Calling destroy probably flushes the stream, however it should do it in end instead. So I think it's a bug in Electron, but a very weird one, which manifests itself only on this OS/DE. Electron in its turn is using this via node.js, and node.js calls the API via libuv.

Meanwhile I tested it everywhere and it seems to be working well. Building a new release...

Done, it's released

yes

Was this page helpful?
0 / 5 - 0 ratings