Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: BrowserWindow size/bounds incorrect when dragging the window from a scaled display to a non-scaled display #32516

Closed
3 tasks done
limacheb opened this issue Jan 18, 2022 · 1 comment

Comments

@limacheb
Copy link

Preflight Checklist

Electron Version

16.0.7

What operating system are you using?

Windows

Operating System Version

Windows 10, verion 21H2

What arch are you using?

x64

Last Known Working Electron version

15.3.4

Expected Behavior

The size set initially to the BrowserWindow shall be maintained after dragging the BrowserWindow from a scaled display to a non-scaled display

Actual Behavior

The test environment includes two diplays:

  1. The laptop display (primary) which is scaled with 125%
  2. An extended regular display.

Screenshots of the display settings page:

image

image



Steps to reproduce

The test application is the regular 'Electron Hello World' application.
Additionally the application shows the BrowserWindow bounds.

Start the test application.
The BrowserWindow constructor sets the width to 800 and the height to 600.

  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })

The application shows up on the primary display as follows:
image

Drag the application onto the secondary display.
The size gets now 25% larger (width is 1000, height is 750), which is wrong.
image

Further dragging the application between the two displays does not change the size anymore (it remains 1000 * 750).

Testcase Gist URL

https://gist.github.com/272f5fa1ad5f363acfa1a753f87200ef

Additional Information

No response

@mlaurencin
Copy link
Contributor

Manually closing as #33231 fixes this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants