fix: handle WM_GETMINMAXINFO instead of letting chromium do it

[brenca]

Description of Change

There is a workaround I introduced that's no longer needed and is causing bugs, so this PR removes that. We had that workaround because during the WM_GETMINMAXINFO message Windows reports a position that's incorrect (somewhere around -32000 for both coordinates), and the handler in chromium calculates the scale factor for the window based on that position, which will be incorrect if you have more than one monitor (the leftmost will be used).

To work around this, we instead handle the WM_GETMINMAXINFO message ourselves, similarly to how chromium does it, but without a size compensation that's not required for us (it compensates for the window frame size, but we expect the minimum and maximum sizes to apply to the window anyway by default, and that compensation code is from 2011, doesn't care about scale factors, and probably should be removed/corrected in chromium anyway).

I'm going to look into upstreaming this new workaround/fix so that we can later remove it altogether.

Depends on #19886.

Fixes #19423.
Fixes #19816.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed a bug where windows would sometimes shrink to 0 size after being restored on Windows.

[whyboris]

Thank you @brenca for the PR -- it will likely fix my issue: whyboris/Video-Hub-App#260 🙇

[ckerr]

@brenca the diff itself looks fine, but could you quickly summarize why this workaround is no longer needed?

[brenca]

@ckerr thanks for the quick review! I realized that removing the workaround does re-introduce a bug, so I changed the code to address that bug and still fix the issues mentioned above.

I'll do some additional testing to make sure things work alright.

[brenca]

@ckerr I added some explanatory comments and made some changes, can I get another review from you?

[codebytere]

lgtm given added context

[release-clerk]

Release Notes Persisted

Fixed a bug where windows would sometimes shrink to 0 size after being restored on Windows.

[trop]

I was unable to backport this PR to "6-0-x" cleanly;
you will need to perform this backport manually.

[trop]

I was unable to backport this PR to "7-0-x" cleanly;
you will need to perform this backport manually.

[trop]

A maintainer has manually backported this PR to "6-0-x", please check out #20001

[whyboris]

Thank you @brenca for working on this bugfix 🙇

Your PR probably closed the other bug, but mine persists as of 6.0.5: #19816 (comment)

[whyboris]

False alarm -- seems like this PR has not been merged into 6.0.5 but instead was released with 6.0.6 https://github.com/electron/electron/releases/tag/v6.0.6 (via #20001 as a backport of this code change) 🙇
I pulled in the code and everything works beautifully 😍

❤️ Thank you @brenca, the Electron team, and all those who help with it 🙇

[carterbs]

@codebytere this PR is causing issues for us on Electron 6 and 7. When we call setBounds on a hidden window, and then show that window on a monitor with a different display scale than the primary....it's the wrong size. But Electron thinks it's the correct size. We've narrowed it down to this PR causing the bad behavior.

The reason we do this is that we have menus that are hidden, and change size based on the contents within the menus. So this bug makes our app look awful in the latest electron versions.

I've reached out to @brenca on slack to see if he has any ideas of how to fix this. It's presently preventing us from keeping up with the latest electron release.

[sgd2z]

@codebytere this PR is causing issues for us on Electron 6 and 7. When we call setBounds on a hidden window, and then show that window on a monitor with a different display scale than the primary....it's the wrong size. But Electron thinks it's the correct size. We've narrowed it down to this PR causing the bad behavior.

The reason we do this is that we have menus that are hidden, and change size based on the contents within the menus. So this bug makes our app look awful in the latest electron versions.

I've reached out to @brenca on slack to see if he has any ideas of how to fix this. It's presently preventing us from keeping up with the latest electron release.

After some testing, I found that I can only reproduce when resizable is false. I'm working on a reproducer.