electron: On Linux, returned position of fixed BrowserWindow gets unexpectedly modified

  • Electron version: 1.7.5
  • Operating system: Linux Mint 18.2 Sonya / Ubuntu 16.04.3 LTS

Expected behavior

On Linux, calling mainWindow.getPosition () should always return the same x and y coordinates when the window is fixed (not moved by the user).

Actual behavior

After creating a main window by new BrowserWindow (), the x and y coordinates returned by mainWindow.getPosition () get unexpectedly shifted by some constant value, depending on which place in the code the function is called from, notably at the end from the window 'close' event handler.

This defeats the possibility of reliably keeping track of the current window state (position and size) between two consecutive runs of the application.

The vertical shift appears to correspond to the height of the window’s title (25 pixels on Linux Mint; 28 pixels on Ubuntu).

The problem doesn’t show up on Darwin.

How to reproduce

$ git clone https://github.com/Mikaeru69/BrowserWindow-Position-Bug-Linux $ cd BrowserWindow-Position-Bug-Linux $ npm install $ npm start || electron .

  • Start the application from a Terminal using the above-mentioned instructions.
  • Don’t move the application’s window, then quit the application.
  • Check the various console.log () outputs:

Linux Mint:

init: [ 200, 100 ] new: [ 200, 100 ] show: [ 201, 125 ] close: [ 201, 125 ]

Ubuntu:

init: [ 200, 100 ] new: [ 200, 100 ] show: [ 200, 100 ] close: [ 200, 128 ]

main.js:

const { app, BrowserWindow } = require ('electron');
let mainWindow = null;
function onAppReady ()
{
    let position = [ 200, 100 ];
    console.log ('init:', position);
    mainWindow = new BrowserWindow ({ x: position[0], y: position[1], width: 800, height: 600, show: false });
    console.log ('new:', mainWindow.getPosition ());
    mainWindow.loadURL (`file://${__dirname}/index.html`);
    mainWindow.on ('ready-to-show', () => { mainWindow.show (); console.log ('show:', mainWindow.getPosition ()); });
    mainWindow.on ('close', () => { console.log ('close:', mainWindow.getPosition ()); });
    mainWindow.on ('closed', () => { app.quit (); });
}
app.on ('ready', onAppReady);

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 4
  • Comments: 31 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Have this problem on the latest VS Code version. Ubuntu 18.04.1 with a GNOME Shell session. After the app (not maximized) is closed a new window of the app is moved down (moving distance - window title bar height).

Please reopen. Still reproducible with current Electron 3.0.2. On my Debian 9 it outputs this:

init: [ 200, 100 ]
new: [ 200, 100 ]
show: [ 200, 100 ]
close: [ 200, 137 ]

I made a screenshot and checked the size of the window title. It is exactly 37 pixels. When opening the window with option frame: falsethen the problem does not happen. So looks like the Electron window position has some problem with the window title bar

Hey there!

This seems to still be an issue on Ubuntu and Electron 8.2.5.

A simple test is to maximize any window and see that its y property on getBounds(), getPosition(), getContentBounds(), and getNormalBounds(), all return > 0 (30px in my case as it’s the title bar’s height), with and without useContentSize.

still there, without a fix or workaround

Thought - could this be to do with the fact that Chrome by default doesn’t show the system titlebar and border?

This is still a problem in Electron 11.4.10. (For the record, on this dev machine I’m required to use CentOS 7 with Gnome to match and enterprise production machine.) One thing I’ve noticed that does not seem correct at all is that getNormalBounds and getContentBounds always seem to return the same y value, even with a titlebar. I would have thought that getContentBounds would provide an adjusted y position, and would only be the same on borderless windows and full-screen mode. I’ve tried using setContentBounds/getContentBounds vs setNormalBounds/getNormalBounds and it seems to make no difference, even on a normal bordered window with a titlebar. The “wrong y by 37” problem I’ve seen above seems to be the right size for the titlebar offset.

For the record, that kludgey workaround was successful. This was a showstopper probem for me, but by intentionally introducing the same bug inverted, it seems to negate the effects of the bug and at least allow me to release my code while this bug remains.

If I specifically give it the wrong y coordinate, with the difference from the desired position, observed in the first move, it ends up at the correct coordinate:

// create main BrowserWindow when electron is ready
app.on("ready", () => {
  // create main window but wait for 'newPrefs' to show it (according to user prefs)
  mainWindow = createMainWindow();
  let temp = mainWindow.getNormalBounds();
  console.log(`Created window at (${temp.x},${temp.y}) of (${temp.width}x${temp.height})`)

  // Ugly workaround for Electron problem: https://github.com/electron/electron/issues/10388
  // Problem: unexpected window move after startup (on Linux only?)
  let firstMove = true;
  mainWindow.on('move', () => {
    let x = prevState.bounds.x;
    let y = prevState.bounds.y;
    syncWindowState('move');
    if (firstMove) {
      firstMove = false;
      setImmediate(() => {
        console.log(`Undo move back to (${x},${y})`);
        let wrongBounds = mainWindow.getNormalBounds();
        x -= (wrongBounds.x - x);
        y -= (wrongBounds.y - y);
        console.log(`Undo move using (${x},${y})`);
        mainWindow.setPosition(x, y);
      });
    }
  });

This produces the desired y (100 in this case):

Created window at (100,100) of (1450x850)
event (init): (100,100) of (1450x850)
event (move): (100,137) of (1450x850)
Undo move back to (100,100)
Undo move using (100,63)
event (move): (100,63) of (1450x850)
event (move): (100,100) of (1450x850)

Note that this means setPosition is failing here. I specifically need to tell it to use y=63 in order for it to end up at y=100.

I’m still active, we just have 1200 issues so this slipped by me 😃

it’s been re-opened: i’m not sure if we can get to this right away but i’ll mark it in a backlog for further investigation.

Since @codebytere doesn’t seem to be active anymore, perhaps @MarshallOfSound can reopen this one? Still a problem in Electron 4.1.3.

This is still a problem in electron 4.0.4 on Ubuntu.