element-hq / element-desktop

A glossy Matrix collaboration client for desktop.
https://element.io
GNU Affero General Public License v3.0
1.14k stars 261 forks source link

Element desktop should remember window size after a restart #686

Open thany opened 2 years ago

thany commented 2 years ago

Steps to reproduce

  1. Start Element and set the window size how you like
  2. Close Element
  3. Start Element again

Outcome

What did you expect?

It remembers windows size & configuration exactly the way I closed it.

What happened instead?

The main window is a lot smaller when it starts, and when I resize it back the way it was, the sidebar also expands which I have to collapse manually.

Operating system

Windows 10 21H2

Application version

Element version: 1.10.1 Olm version: 3.2.8

How did you install the app?

No response

Homeserver

No response

Will you send logs?

No

t3chguy commented 2 years ago

Defect because we call upon electron-window-state to handle this for us, but it hasn't been updated in 3 years and may have some bugs

thany commented 2 years ago

If it's not been updated, how come it suddenly started having this problem? This is a regression, mind you. Previous version did not have this problem.

Something must've been changed in order for this bug to surface.

Btw, I wouldn't consider this occasional. It's 100% reproducible for me, on two different pc's. (does that make it 200% reproducible? 😀)

t3chguy commented 2 years ago

If it's not been updated, how come it suddenly started having this problem?

Electron has been updated, so the interaction between Electron and some code which relies on Electron behaving in a specific way will change, even if only half of that whole has changed.

thany commented 2 years ago

So it has been updated. I thought you wrote it hadn't been. Okay.

Well, another indicator is that the title bar of the inactive Element window now has the wrong colour. It no longer reflects the Windows colours/theme/personalisation anymore.

Perhaps that's another indicator of where to go looking for a solution.

Honestly, I would advise to revert those changes for the time being.

t3chguy commented 2 years ago

So it has been updated. I thought you wrote it hadn't been. Okay.

No, electron-window-state hasn't been updated, but Electron has. Just like if you update from Windows 10 to 11 some software can stop working the same as it used to.

t3chguy commented 2 years ago

Honestly, I would advise to revert those changes for the time being.

Reverting Electron means downgrading Chromium which brings back a lot of browser upstream bugs, especially around accessibility so is a hard no.

thany commented 2 years ago

Okay, fair enough. But let's start thinking about possibilities, rather than impossibilities.

If electron-window-state is the culprit, replace it, insource it, fix it, or take a different approach. Maybe look at what solution other apps have chosen to remember window size&position. VScode is very mature, and is opensource. Maybe look thereabouts.

But it's important to know for sure if said package is causing this, so you're not going to run at full speed in the wrong direction 🙂

thany commented 2 years ago

Seeing that this is a regression, has this issue gotten any headway yet? It's kind of really important that the very start of a program (literally starting it up) does get onto a user's nerves. Also, regressions should get elevated priority.

claell commented 2 years ago

Just ran into this. It is especially bad on a multi monitor setup.

thany commented 2 years ago

It's really disappointing not to have a solution after 6 months. I'm sure you're busy, but this stands out to me twice a day, and any additional times I have to do a reboot.

I cannot, in good conscience, recommend this program to friends & colleagues, beause they too all have multimonitor setups (on which apparently this is more obvious - I wouldn't know, it's always obvious to me). And a bug that feels like it should be so damn easy to fix (don't know if it is, but it feels that way) is a real letdown for firsttimers, because they will encounter this bug and go "like, what, have they ever opened this program themselves? are they not SEEING this?", I would imagine.

But I digress. Since this issue is so bleedingly obvious, and it's been sitting for half a year, please elevate priority.

t3chguy commented 2 years ago

And a bug that feels like it should be so damn easy to fix

You're welcome to try, the power of open source and all that.

We're currently using https://www.npmjs.com/package/electron-window-state but it seems abandoned and has outstanding issues.

thany commented 2 years ago

You're welcome to try, the power of open source and all that.

The default opensource way to brush off an issue. Because everyone who reports an issue, is magically a programmer and had knowledge of the exact packages and technologies used.

Anyway, had priority been raised? Has anyone done anything to look into it? I don't have to re-iterate how absolutely monstrously obvious this bug is, do it? You know, the fact that every single time the app starts, it starts with a window in the exact right location, but 2-3x too small? Yeah that one, that problem that presumably everyone with two different monitors is having. So basically everyone with, say, any laptop and any external monitor hooked up.

Maybe not rely on external packages to do something so seemingly benign as remembering X, Y, Width, and Height of your application window? I don't know, but it seems pretty damn basic to me.

t3chguy commented 2 years ago

I don't know, but it seems pretty damn basic to me.

If it was basic then the package probably wouldn't be buggy, no? It has ~25k weekly downloads.

Lots of apps implement it themselves with buggy behaviour - anecdotes and open issues linked from https://github.com/electron/electron/issues/526. Handling resolution changes, monitor changes, etc isn't trivial.

thany commented 2 years ago

My setup doesn't change between starts. It should be as trivial as remembering X/Y/H/W.

thany commented 1 year ago

Since this issue reproduces 100% of the time on multiple computers, I shouldn't think this would be too hard to get reproduced...

So, do you need more information to solve this? Is there something you don't understand yet? Do you need help, or pointers, or anything at all?

One thing I personally don't understand, is how this bug is allowed to linger on for many releases, even though it is so blatantly obviously there. Doesn't it like, super obviously stand out to anyone else, literally every time the program starts?

t3chguy commented 1 year ago

To fix this personally I'd need a swathe of environments to test it on whilst developing, handful of different Linux DEs specifically. This isn't something I would have time to go off-piste on. We rely on a library to handle this for us to act as the abstraction layer between all the various types of environments, obviously the library has issues of its own. There are a lot of possible edge cases to handle here, this simply isn't as trivial as one would think. I personally don't have the issue on my macOS developer machine or my Windows personal machine.

thany commented 1 year ago

It happens on Windows. You won't need a million VMs with all variations on every OS, just a Windows 10 box. It happens on all three of my Windows machines.

t3chguy commented 1 year ago

It doesn't happen on my Windows 10 machine. Not sure what you want me to tell you.

thany commented 1 year ago

I'm waiting for questions then. What do you need from me?

t3chguy commented 1 year ago

Nothing? This issue doesn't have an X-Needs-Info label? It needs someone to be tasked with fixing it, or a fix to be made upstream.

thany commented 1 year ago

Then why are you telling me basically "works on my machine"? That's just adding to my frustration. That's always adding to a reporter's frustration. Wouldn't you be annoyed when you report something broken and they're telling you "nope, works fine here"?

Anyway, good that it works for you. Keep it that way. Don't break it on your own machine while fixing it, I guess.

soonic6 commented 1 year ago

Version von Element: 1.11.28 Version von Olm: 3.2.12

Edition Windows 11 Pro Version 22H2 Installiert am ‎21.‎09.‎2022 Betriebssystembuild 22621.1413 Leistung Windows Feature Experience Pack 1000.22639.1000.0

will not remeber windows size, position and monitor.

thany commented 9 months ago

I have two scenarios to share, because it (still) goes wrong in two different ways.

Scenario 1 - a laptop

It has an internal primary display at 3840x2400 zoomed to 250%, and an external secondary display at 3840x2160 zoomed to 200%.

Currently, every time element starts, it starts on the internal display. Every time it does, the window size is correct for how I left it when it closed, so I "only" have to drag it to the external display and leave it there.

I say currently, because earlier in the year for a few months it decided to start at the correct monitor, but its window would be too small (similar to the next scenario).

Scenario 2 - a desktop

It has a primary display at 3840x2160 zoomed to 200%, and a secondary display at 1280x1024 zoomed to 100%.

Currently, every time element starts, it starts on the secondary display, but the window is roughly half the size (in both dimensions) as how I left it when it last closed.


So two things are wrong, and the weird part is that they are two different (albeit similar) wrongs, on otherwise identical Windows and Element versions and configurations. The only difference is the layout of the two monitors.

There must be some point where Element can be bothered to store (or load) its window location & size, because it can remember window size, and it can remember window position. Either isn't always saved (or loaded) correctly, while the other is. It's almost like it can save/load ONLY the window size, or ONLY the window position, but never both.

ghost commented 8 months ago

this is still an issue (on linux and wayland btw), what the hell? why not store window size and position in a file and load from there?

thany commented 8 months ago

This is an issue on every pc, trust me.

Except of course @t3chguy seems to be having a "works on my machine" situation, and no means to reproduce it even though I've written an essay sized comment on the exact configurations where it is 100% guaranteed everytime fully reproducible.

That aside, I dunno either, @nvkomata, it seems pretty basic to me.

t3chguy commented 7 months ago

this is still an issue (on linux and wayland btw), what the hell? why not store window size and position in a file and load from there?

What do you think the window-state.json file is?

image

ghost commented 7 months ago

this is still an issue (on linux and wayland btw), what the hell? why not store window size and position in a file and load from there?

What do you think the window-state.json file is?

image

okay but stop ignoring the fact that it's evidently not doing shit, there still is an issue

thany commented 4 months ago

@t3chguy

What do you think the window-state.json file is?

image

If you want my honest opinion: I don't care what it is. The point is that it doesn't work correctly. That's all there is to it.

So let me ask you a counter question: why is it so hard to get an application to remember its window size & position correctly? Please bare in mind that for me, Element is the only application that can't do this. And I have multiple webtech-based desktop applications that I use daily.

fabiencharrasse commented 3 months ago

Hello, I also see the same problem.

Element 1.11.69
Linux Mint 21.3

I don't know if this can help, the problem also exists on Firefox/Thunderbird. (At least for Linux Mint)

thany commented 2 months ago

How is it going, as for fixing this issue?