Signal-desktop: [Signal Desktop] Preferences window shows up as a floating frame on secondary monitor.

[stpr-dev]

• [X] I have searched open and closed issues for duplicates
  

---

Bug Description

I have two monitors with different resolutions (the active monitor is a 1440p monitor, the secondary monitor is 1080p monitor). Opening the preferences window on Signal Desktop causes the preferences window to show up on the secondary monitor, and additionally, it shows up as a floating frame on the non-active monitor. The resolution (scaling) of the floating frame also appears to be weird.

The secondary monitor issue appears to not be an issue particularly fixed to preferences, but other windows such as "About" or "Debug Log". These do no respect the primary monitor and always show up on the secondary monitor.

Steps to Reproduce

1. Launch signal desktop.
2. Open Preferences window (File -> Preferences).
3. Expect to see preferences in the same window or a new window on the active monitor.

Actual Result:

Notice that the preferences window does not appear either in the same window or new window, and even on the active monitor. Instead, it is on a floating frame in the other monitor. I am unable to switch to it using the OS's window switcher. I am forced to minimize all windows on the secondary monitor to access this floating frame.

Expected Result:

Expect to see preferences in the same window or a new window, and also on the active monitor.

Screenshots

Multi-monitor screenshot:

Platform Info

Signal Version:

v1.37.2

Operating System:

Distro: Arch Linux x64 (Kernel version: 5.9.2)
Desktop Environment: KDE Plasma 5.20.2

Linked Device Version:

4.75.4

Link to Debug Log

Not sure that it helps, but here it is anyway.

[mjsr]

I can reproduce on Windows 10.

Moreover, I noticed this doesn't happen with all the dialogs for me. I've listed the ones that open in the same monitor as the Signal desktop app.

My setup: Signal Desktop app is in monitor 1 and the Preferences show in monitor 2.

As I pointed, I found out that the behavior is not consistent with all dialogs although I understand that they might have underlying differences I am currently not familiar with. For that reason, I'll list them in two categories: the ones that open in a different monitor and the ones that behave as expected:

List of dialogs that open in a different monitor

• Preferences
• About Signal Desktop
• Debug log

List of dialogs that open in the same monitor

When I move the Signal window to the monitor 2 and reopen these dialogs, it opens in the same monitor where Signal is.

• Create/Upload sticker pack
• Show Keyboard Shortcuts - this doesn't appear to be a different dialog but instead just an overlay on the main window.

Versions

• Signal v1.37.2-beta.1
• Linked device version: 4.75.7 (beta)
• Windows 10 v1909 build 18363.1139 up to date.

How to solve

From looking at the code for a brief moment (I'm not familiar with the app itself, just trying to help here), I would say:

• in my particular case, I see that window is defined in ephemeral.json in my %appdata% directory.
• the windowConfig in main.js appears to contain these settings.
• looking at the window that behaves correctly, the sticker creation code we can see that we're using the windowConfig and add an offset of 100px in x and y axis.

My conclusion is to replicate similar code for the other window creation to make them relative to the main window.

Note: I am currently uncertain if I am able to sign the CLA (clause 4 - employer restrictions might apply :( ).

[mjsr]

I read into the Electron API and this will not be experienced on macOS.

On macOS the child windows will keep the relative position to parent window when parent window moves, while on Windows and Linux child windows will not move.

Source: https://www.electronjs.org/docs/api/browser-window#platform-notices

[mjsr]

As stated before, I don't believe I can sign the CLA therefore cannot create a pull request. However, nothing prevents me from doing on my repo: https://github.com/mjsr/Signal-Desktop/commit/c8ab2634c30fff8e1255962b328a19022472419a

Note that I'm not very familiar with the codebase, electron or JS in general. My intention is merely to help since I really believe in what the Signal app stands for.

[fresheneesz]

I definitely also see this with the current version of the desktop program. Would be nice to see that pull request pulled in.

[scottnonnenberg-signal]

Please watch for our next production release - we do expect this to be fixed there. If you're willing, we'd also love to have more windows users running our beta - you can install that with the links here: https://support.signal.org/hc/en-us/articles/360007318471-Signal-Beta

[stpr-dev]

I can confirm that (at least on Arch Linux with signal-desktop 1.40.0-1, this problem is resolved. I am closing the issue unless other platforms/users still have issues with it.