element-hq
Start at login not working
Description
"Start automatically after system login" isn't working for me. It's definitely enabled, but at least today, Element didn't start when I logged in. I installed it yesterday on this computer, so I don't know if it's a one-off or not. But it seems like something that either always works, or never works.
Steps to reproduce
- Install Element
- Enable said option
- Shutdown computer
- Go to sleep
- Startup computer
Logs being sent: yes
Version information
- Platform: desktop
- OS: Windows 10 20H2
- Version: 1.7.20
Same here, element-web is starting and it show me the rotating circle... and nothing more.
OS : Arch-Linux Name : element-web Version : 1.7.21-1 Beschreibung : Glossy Matrix collaboration client — web version. Architektur : x86_64
@thany What symptoms do you see? Is it different from @EmJotGeh? I assumed @thany meant that nothing about the app appears at all: no window, no tray icon, nothing.
@jryans Correct, for me, the app doesn't start at all. The whole process just isn't running as soon as I'm able to check for it.
Worked around by placing it in the "Start-up" folder in the start menu. It still starts on the wrong monitor and and the wrong virtual desktop, but at least it starts.
@thany About the window state, trying clearing out <USER>\AppData\Roaming\[Element|Riot]\window-state.json.
As for launching, what path does it create in the registry when the option is enabled at HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run in RegEdit?
Today the problem solved. I tried to start Element without a password - only enter for the KWallet password manager. Element started normal - without the functionality for encrypted rooms. That's good and after the second start it seems that Element work fine again.
@jryans I really don't think clearing window state will help, but I'll give it a go. The reason I say this, is because I've done a totally new & vanilla install. I openened this issue about a day or two after this particular pc recieved it's very first installation of Element.
Also, since a few days it does now start on the correct monitor, but not yet on the correct virtual desktop (which seems to be a recurring problem among many other programs, so perhaps it's extremely difficult to get right).
As for launching, what it puts in there is this:
"C:\Users\<user>\AppData\Local\element-desktop\update.exe" --processStart "Element.exe" --process-start-args "--hidden"
If I launch that manually, while Element is not running, it also doesn't start. It appears absolutely nothing happens when I execute that command. And as for the "hidden" option - Element also doesn't appear in the notification area, which is what hidden could be indicating. Nor does it go anywhere else.
When I launch the "normal" launcher:
C:\Users\<user>\AppData\Local\element-desktop\Element.exe
It starts correctly.
@thany I'm currently looking into this issue
If you exit Element first, and execute the following in a terminal window
"C:\Users\<user>\AppData\Local\element-desktop\update.exe" --processStart "Element.exe" --process-start-args "--hidden"
Do you have any error messages that pop up there?
For me everything run as expected, the app is booting up but is hidden, I can see it if I expand the opened app in the "opened app tray" next to the clock in the bottom right of the screen. Would it be possible that the app is hidden there for you too?
Nope. No error messages, nothing. The app does NOT start in the notification tray. It doesn't start at all. It doesn't even appear in the task manager.
I'm sure that command is doing something, but it definitely doesn't start the app.
@thany Hmm, so this is quite puzzling overall... I believe you're the only one hitting this issue, so we'll need to work out what's specific to your configuration.
For the <user> value in "C:\Users\<user>\AppData\Local\element-desktop\update.exe", does it contain spaces for you? Does it contain any non-ASCII characters?
It's a bit of a wild guess, but I'm just trying to imagine what could be specific to your system about this...
@jryans It only contains ascii-characters and a dot. I don't think that's the culprit, since the normal launcher works fine.
Oof, I just discovered on a different laptop, that this is still not working.
Similar configuration though. Windows 10, all up-to-date. Only on this machine, my username doesn't contain a dot, so that wasn't the culprit.
Can I just ask: what does make it work? What exact circumstances need to be met? Can you explain what the autostart actually starts and does, line by line, so to speak? That might help track down why it isn't working... On multiple machines now.
No idea. I've already put it in the regular Startup folder, where applications should put themselves for start-on-login in the first place, and that works a charm.
So, problem is NOT fixed, so please refrain from closing this issue. But this as a workaround is managable.
Without reliable reproduction steps or information about modern releases having the same issue, we can't really keep this open. Happy to keep it open for the maximum allowable time under our triage process though in hopes of someone providing additional detail.
Same problem here. Note that I can't change the setting "Start automatically after system login", which is enabled: a click on it doesn't disable it.
Element: 1.10.15, Olm: 3.2.8, Windows 11, all updated. Same problem as OP and I also cannot change the setting (it's enabled always, but it does not work).
I think the fix is evident.
The switch in All Settings should put Element (starting the normal Element.exe) in the Startup folder in the start menu. Couldn't be simpler. This is how Windows starts a program at logon, and it's also visible to (and managable by) the user without having to dive into the settings (or worse, the registry).
Starting programs this way always works. Of course, you'd have to start the correct executable. Update.exe does not start Element. Sorry guys, it just flipping doesn't. I don't know how it doesn't start it, but it doesn't.
And since I never got an answer of any kind to
Can I just ask: what does make it work? What exact circumstances need to be met? Can you explain what the autostart actually starts and does, line by line, so to speak? That might help track down why it isn't working... On multiple machines now.
I have to assume you (the devs) don't know either, which is weird and unsettling. I mean, how hard can it be, realistically, to just spawn Element.exe from that magical update.exe? But more to the point: update.exe is either not needed because the app can update itself perfectly well, or (and I'm starting to repeat myself) it is not intended to start the app but only to update it.
Element Desktop does not start automatically for me either. In settings „Start automatically after system login“ is active. But it doesn't start on login. Ubuntu 22.04 LTS, Element Desktop 1.11.0 .
Well, I*ve the same issue, no auto-start after login: Element Desktop 1.11.1 on Debian 11.4.
I've just figured out, that the corresponding Element option is enabled when you add Element to Gnome "Startup Applications".
Taskmanager -> Startup Check the tool "Update" by "GitHub" if its enabled.
elements and discords entries are silly like that. I disabled those first, too. Assuming its the updater for git. No it isnt.
@Nama
elements and discords entries are silly like that.
I disabled them because they aren't working. The problem is exactly this updater: it starts and then immediately stops, and that's the end of it.
The autostart should start the application, not some updater. The application can already update itself perfectly fine, thank you very much, so bootstrapping the application (and also failing to do so) with yet another pointless moment of checking for updates, is indeed pointless.
With Squirrel.Windows the only constant path you have is the updater, the application executables are named by version so the autostart could drift from the updated version and then fail, hence following the guidance of Squirrel.Windows you should always start via the updater.
That is a disadvantage of your own doing. You could also keep the executable the same, like most software does. Or have the updater also update the autostart entry.
Again, you're thinking in terms of impossibilities, rather than oppertunities. You're not being constructive. I don't know the software inside out, so I can only do as much as point out that something appears to be weird in regard to other software, and doesn't work correctly as a result. And you're going "oh that's not possible because of such and such", well I don't care what's not possible. I care about what is possible.
So the question remains, what can be done to solve this problem?
Edit: also no it's not even true what you're claiming. The executable is:
C:\Users\<username>\AppData\Local\element-desktop\Element.exe
Where is a version number?
That is a disadvantage of your own doing. You could also keep the executable the same, like most software does.
It is just how Squirrel.Windows (the Electron updater) works, it doesn't have any other mode than this.
Or have the updater also update the autostart entry.
This is not something Squirrel.Windows can do, feel free to suggest it at https://github.com/Squirrel/Squirrel.Windows
Where is a version number?
That is also an executable of the updater, unless you think the entire app fits within 268KB.
The real executable is in the versioned directory
It is just how Squirrel.Windows (the Electron updater) works, it doesn't have any other mode than this.
Again, not really my concern as a user.
This is not something Squirrel.Windows can do, feel free to suggest it at https://github.com/Squirrel/Squirrel.Windows
That's not up to me, as I am not using this package, and I wouldn't know how to properly create a bug report there. You know much better what is going wrong at that level.
That is also an executable of the updater, unless you think the entire app fits within 268KB.
I dunno, it may well do. But that's what I point my own autostart entry at, and that one works. The one set from within the application doesn't, so it must be different.
So, you can explain the problem in the greatest amount of detail, and other developers will thank you for that. But in the end, an explanation isn't a solution. It may lead to one, but having explained the problem means you're only (or already) halfway there.
I don't have access to a licensed Windows environment, so I'm far from half way. I've also not been allocated any time beyond triage to this issue.
Windows can be downloaded for free, legally, without activating, indefinitely. You'll just miss out on desktop customisation features.
The issue still requires prioritization from the team or another community member, even when access to a Windows machine is available.
PRs are extremely welcome here.