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)
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:
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 barHey 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
yproperty ongetBounds(),getPosition(),getContentBounds(), andgetNormalBounds(), all return > 0 (30px in my case as it’s the title bar’s height), with and withoutuseContentSize.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
getNormalBoundsandgetContentBoundsalways seem to return the sameyvalue, even with a titlebar. I would have thought that getContentBounds would provide an adjustedyposition, and would only be the same on borderless windows and full-screen mode. I’ve tried usingsetContentBounds/getContentBoundsvssetNormalBounds/getNormalBoundsand 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
ycoordinate, with the difference from the desired position, observed in the first move, it ends up at the correct coordinate:This produces the desired
y(100 in this case):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.