electron.screen.getAllDisplays( ) keeps returning initial screen available space

[pouyakary]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  v5.0.2
• Operating System:
  macOS 10.14.2
• Last Known Working Electron version:
  -

Expected Behavior

The screen module of the electron package has a method called getAllDisplays which should return the size of the screen as well as the available space for the app. In Mac, the dock size is dynamic and therefore by changing the size of the dock, the available space should change as well.

Actual Behavior

As you can see, regardless of the dock size the system returns a constant 701 number

[codebytere]

@pmkary i can dig into this a bit: but we don't presently change anything as it's filtered through Chromium's screen capture code, and it does not seem that code currently takes occlusion by dock into account when making these calculations.

[pouyakary]

@codebytere — Shelly, hi! thanks a lot for looking into it.

For multi-window software (say financial terminals) of which window management is internally handled, it is very important since we get windows under the dock by API fault all the time. So if it was possible to have the API use native OS calls instead of chromium, it could be marvelous.

[bpasero]

@deepak1556 @codebytere I wonder if microsoft/vscode#74872 is related, which is a regression we see after updating to Electron 4.2.3. It looks like a Window cannot become larger than the primary display bounds if multiple monitors are used.

[MarshallOfSound]

@bpasero I don't believe that these issues are related (at least at a glance). Could you try (wherever you are restoring the position), calling setPosition / setBounds twice in a row instead of once? Just to help me check a theory.

[pouyakary]

@codebytere • I gathered a little bit more of info into this. Changing the position of the dock ( bottom / left / right ) also does not make any difference too as well as hiding the menubar. So for it seems that the chromium API computes the available area only once and then keeps returning those numbers regardless of the changes.

[pouyakary]

@bpasero • @MarshallOfSound • I think that Benjamin is right about these issues being connected. We encountered the same issue as vscode's 74872 on a multi-window system where we had to manually align windows on multiple monitors and changes in monitors did break the system. Our windows ended in strange places like under the mac's menubar. At that time we used OpenFin (an electron fork) so we thought it's OpenFin's API fault, (it kept returning initial monitor/display info). But now that I see this within API of electron and since our issues are pretty much the same, I'm 100% certain the two issues are connected.

[bpasero]

@pmkary does your issue reproduce in Electron 4 and not in 3?

[pouyakary]

@bpasero — We used OpenFin which didn't specify its version mapping to electron, but I can test it on an electron playground. So I'll be testing it

[bpasero]

@MarshallOfSound I can confirm that the following workaround makes the issue go away:

• create the window (with the proper size)
• call win.setBounds() after that with the same values

Is this a known issue? Does it impact other OS than macOS? Should we go with this workaround? I think this should also be conditional when more than one monitor is used as I do not think this issue reproduces on a single monitor.

//cc @deepak1556

[bpasero]

I pushed this workaround for VS Code.

[bpasero]

@bpasero I don't believe that these issues are related (at least at a glance). Could you try (wherever you are restoring the position), calling setPosition / setBounds twice in a row instead of once? Just to help me check a theory.

@MarshallOfSound this is actually causing yet another issue (microsoft/vscode#75830) when using macOS native tabs. Here is what happens (macOS native tabs enabled in VSCode):

• you start with one window and maximize it
• you open a second window
• this adds a new tab to the native tab bar (provided you have configured to always open as tab when opening new windows)
• I then call setBounds() with a value as workaround (having our default window size 800x600)
• the window now resizes to that value, even though it should not resize given the first window dimensions are already correct

I will have to add another workaround to never call setBounds() when there is more than one window opened, which is odd.

I think when passing in the window dimensions as constructor to the BrowserWindow, Electron (or macOS) nicely handles the fact that the window either opens as standalone window or as a tabbed window and in the latter case ignores the size.

[carterbs]

+1 that this issue is causing us grief. We want to position a window at the bottom of the monitor. My expectation is that workArea and workAreaSize will change as the dock's position changes.

If you have a dock that moves from monitor to monitor, Electron only returns the dimensions at application start.

[electron-triage]

The Electron version reported on this issue is no longer supported. See our supported versions documentation.

If this is still reproducible on a supported version, please open a new issue with any other new information that a maintainer should know.

Thank you for taking the time to report this issue and helping to make Electron better! Your help is appreciated.

[bpasero]

This issue should be reopened, even with latest Electron 28, I need to call setBounds on windows to properly restore the size in a multi-monitor setup when resolutions are different.