[Bug]: Full screen overlay doesn't cover the entire screen

[DanielSWolf]

Version

• [x] I'm using version 1.17.2

Known issues

• [x] I've checked Known issues

Existing issues

• [x] I've checked Existing issues

Advanced Preferences

• [x] I've checked Advanced Preferences

What operating system are you using?

Linux

Operating System Version

Ubuntu 24.04.2 LTS

Reproduction steps

1. Enable full-screen breaks
2. Wait for the next break

Reproduces how often: 100%

Expected Behavior

The full-screen break overlay fills the entire screen.

Actual Behavior

The full-screen break overlay is one pixel too small in each dimension: The right-most pixel column and the bottom-most pixel row aren't covered.

Relevant log output

Preferences

Additional information

This happens only on Linux. On my Windows machine, everything is covered as expected.

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[hovancik]

Sorry for late reply, GH is not sending me emails for some reason so I did not notice this.

Is this one or multiple monitors? Which DE?

[DanielSWolf]

I normally use 2 screens, but it happens with a single screen, too. I'm using GNOME.

[hovancik]

Testing now on Debian/KDE and all is fine there. I also have XFCE and Enlightment so will try there.

[hovancik]

Same on XFCE and Enlightment. @DanielSWolf can you please try with 1.18? Or then it is Gnome specific issue.

[igorsantos07]

It seems to happen on macOS as well, under v1.19.0... Except the space is waaaaaaaay bigger than with the OP. I actually thought it was intentional 😂

It happens on both my screens, the left one being an ultrawide screen, and the other a normal wide screen, but on portrait.

[hovancik]

@igorsantos07 is that with Fullscreen enabled? By default, the breaks look like on your screenshot, they cover around 80% if I remember correctly. But you can change to fullscreen in preferences.

[igorsantos07]

Whoops 🙈 So I guess it was my bad.

[DanielSWolf]

can you please try with 1.18?

@hovancik The issue still persists with Stretchly 1.19.0. Is there any additional information I can give you?

[hovancik]

@DanielSWolf do you have some other DE installed by any chance? So we can check if is ubuntu or gnome thing. I've tried on Debian (KDE, XFCE, Enlightenment) and all was ok, but I do not have Gnome.

[DanielSWolf]

I just built and debugged Stretchly locally.

• The call to displayManager.getDisplayBounds() returns {"x":0, "y":0, "width":3440, "height":1440}, which is correct (no off-by-one error here).
• In main.js, the bounds are correctly passed to both new BrowserWindow() and microbreakWinLocal.setSize().
• However, if I read back the size immediately afterwards using microbreakWinLocal.getSize(), I get [3439, 1439].

So this seems to be an off-by-one error in Electron.

I found this old error report, which might be the same issue but has been closed without fix.

A very stupid workaround that works for me is this:

if (microbreakWinLocal.getSize()[0] === windowOptions.width - 1) {
  // Workaround for off-by-one sizing error in Electron
  microbreakWinLocal.setSize(
    windowOptions.width + 1,
    windowOptions.height + 1
  );
}

[hovancik]

Thanks for looking into this! Can you please send PR? I wonder where you put this but I guess after window gets shown?

Even better check could be:

• save into some variable the size we expect see
• then if it is not as expected, make the change

So we cover if some other platform/os/whatever decides to be 2px difference or sth similar :)