Client: Start Keybase Minimized on startup

[olback]

Title basicly says it all...

It would be nice if there were an option to start Keybase minimized on startup.

[Dessix]

This is probably my biggest qualm with Keybase so far.

[drdaeman]

This is extremely annoying, especially when app decides to update itself and restarts - bringing itself into focus all of sudden. Any non-interactive action (run on startup, internal app restart, etc), shouldn't bring the UI into focus.

(Also, app shouldn't pop up all of sudden if it has something to display, but make use of OS notifications facilities - but that's another issue.)

[Texxer]

Can we push this? It's actually not so hard to fix...

[heronhaye]

This should already be the case on Linux. Which OS are you all using?

[mati865]

Arch Linux repository package doesn't start minimised.
AUR package is fine.

[heronhaye]

@mati865, sorry, the community package is not maintained by us. cc @eli-schwartz

If you run the GUI with the environment variable

KEYBASE_START_UI=hideWindow

it will start but not pop up. If you're using systemctl to start the gui, you can specify it in the environment file at $XDG_RUNTIME_DIR/keybase/keybase/gui.env.

Note that that environment file is overwritten by run_keybase (which is not present in the community package). In keybase-bin, KEYBASE_AUTOSTART=1 is set before calling run_keybase in .config/autostart/keybase_autostart.desktop so the gui is minimized on startup.

[eli-schwartz]

Perhaps the systemd service could set this variable automatically, and the launcher script which is run from the desktop file should optionally trigger the GUI to be raised into the foreground?

[eli-schwartz]

I'm currently pushing an Arch Linux update to the latest keybase release (2.13.1) which modifies the service and XDG autostart to set KEYBASE_START_UI=hideWindow.

Re-executing the application while it is already started will bring it to the foreground, whether that variable is set or not (and then it will bail out with the message "Only one instance of keybase GUI allowed"). This is probably a bug...

The functionality of foregrounding it is useful for the purposes of my last comment, but my current check uses an if [ "$KEYBASE_START_UI" != hideWindow ] to determine whether to re-exec the app as a foregrounding signal, and it would make more sense to just exec it followed by letting the app decide whether to foreground in addition to starting it if it is not started yet.

[heronhaye]

@eli-schwartz So the user will need to click the desktop icon twice to foreground Keybase? It seems a bit confusing to me but it's up to you.

Would you mind also setting KEYBASE_AUTOSTART=1? I was going to change the GUI code from checking KEYBASE_START_UI in the next release because it's a bit cleaner and because we may want other behavior on autostart as well. That being said, GUI will continue to be backgrounded if only KEYBASE_START_UI=hideWindow is set for backwards compat.

[eli-schwartz]

The current state of things is I'm reimplementing the bit of functionality I need, rather than using run_keybase which does all sorts of things including running the root redirector I refused to ship and which turned out to have the classic security holes with suid binaries. :p

I only bothered with KEYBASE_START_UI because the current version only checks that -- I can adapt to other things too, but my ideal is to figure out how to do this consistently with the upstream versions of the desktop and autostart files so I need to do less patching...
Checking KEYBASE_AUTOSTART is less patching too (one less thing for me to sed in the autostart file), so if the electron app switches to checking that first, I'll simplify onto that.

As for the current workflow, it works with only one click and user-facing behavior should be preserved.

Starting the keybase GUI in the Arch package is always done by activating the systemd service, which sets KEYBASE_START_UI=hideWindow unconditionally. If started via the wrapper script /usr/bin/keybase-gui, and the KEYBASE_START_UI=hideWindow is NOT set, an additional call is made to electron /usr/share/keybase-app in order to trigger the application into the foreground, still on the first click. This ensures that it is not foregrounded via the autostart file.

Some/all of this workflow could potentially make sense for the official keybase release scripts too, as it means the envvar forwarding has less to do (and on Arch which already forwards DISPLAY, maybe nothing).

[heronhaye]

What happens if the user runs systemctl --user restart keybase.gui with a foregrounded app? Does it get backgrounded?

as it means the envvar forwarding has less to do (and on Arch which already forwards DISPLAY, maybe nothing).

How would we, for example, know $XDG_DOWNLOAD_DIR?

[ThiefMaster]

Two years later, still no fix for this annoying behavior... 😿

[heronhaye]

@ThiefMaster what operating system and package are you using?

[sersorrel]

Different person, but I'm on Ubuntu 18.04, using the official deb package, and I just installed an update through update-notifier that resulted in a Keybase window opening.

NB: I'm using i3, which doesn't have a concept of minimised windows, so starting Keybase minimised would not help me – but just _not opening a window on updates_ would!

[eli-schwartz]

@anowlcalledjosh the whole "loop through users on the system that are running the program, su to that user and kill then restart the program" on a package update is pretty insane and my unofficial Arch Linux packages will never do that. I'm pretty sure if a Debian developer ever packaged keybase for Debian, they would disable refuse to implement it too.

That being said, according to https://github.com/keybase/client/blob/535df047493eee05e5444c28883dc3805b37cfce/packaging/linux/post_install.sh#L22-L24 you should be able to manually disable this.

[sersorrel]

Honestly it's not the autorestart that bothers me; it's that no other application on my system which autostarts opens a window when it does so. But that's a useful workaround, thanks :)

[eli-schwartz]

It's not a "workaround" -- it's just inappropriate to #YOLO kill and restart an interactive GUI application. It's even a matter of strong debate whether the Debian approach to autorestarting daemonized system services (or #YOLO enabling them in the first place) is okay, but at least this dangerous, ill-advised, insecure, non-user-friendly functionality can be disabled if you know you need to do it.

YOLO restarting a window which the user might be in the middle of typing into is simply... lame. The fact that keybase does it at all is the reason why you have an issue in the first place, so it stands to reason that disabling inadvisable non-features would fix the buggy behavior you are dealing with.

[heronhaye]

@eli-schwartz yeah, we're looking to move toward a system like Firefox where you are prompted to restart in the GUI after an update instead.

@anowlcalledjosh Unfortunately we don't have a good way of detecting whether the window is already maximized or not that works across all wms right now. As Eli mentioned, you can run this to stop autorestarting. Note that after you update keybase, you'll have to run run_keybase manually to get the latest version.

echo '{ "disable-autorestart": true }' | sudo tee /etc/keybase/config.json

Test by running sudo /opt/keybase/post_install.sh, which is what's run after update.

[s0m3guy]

How is this still an issue? I can't imagine it to being that hard to fix and it's SO annoying :/

[heronhaye]

It should work. @s0m3guy if you run run_keybase -a in terminal, does keybase start maximized?

[s0m3guy]

I'm on Windows 10 and tried a shortcut with -a and it doesn't work

On Thu, 9 Jan 2020 at 23:49, heronhaye [e-mail] wrote:

It should work. @s0m3guy https://github.com/s0m3guy if you run run_keybase
-a in terminal, does keybase start maximized?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/6031?email_source=notifications&email_token=AANZYY2FIMZAA3ZXKYGEJ7TQ46SX5A5CNFSM4DBPKV52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEISCBAI#issuecomment-572792961,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANZYY453YILWX5L556DZETQ46SX5ANCNFSM4DBPKV5Q
.

[heronhaye]

It should work. @s0m3guy if you run run_keybase -a in terminal, does keybase start maximized?

Scratch that, it looks like this broke on Linux systems with systemd. I'll get a fix out for the next release.

@s0m3guy
Sorry about that. We'll check this out on Windows.