[Bug]: setSize on BrowserWindow during will-resize is applied on mouse-up and not immediately

[WilfredC64]

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 a bug report that matches the one I want to file, without success.

Electron Version

17.4.0

What operating system are you using?

Windows

Operating System Version

Windows 10 Pro 21H2

What arch are you using?

ia32

Last Known Working Electron version

17.3.1

Expected Behavior

When calling the setSize on a browser window in the main process during the will-resize event, the width and height should be applied immediately in combination with the preventDefault on the event.

Actual Behavior

When calling the setSize on a browser window in the main process during the will-resize event, the width and height isn't set immediately anymore in combination with the preventDefault on the event. When you resize the window and during will-resize event you set the size of the window (for e.g. handling minimal width and minimal height), the new size isn't affective immediately. The size is applied when you stop resizing by a mouse up. With Electron version 17.3.1 and lower the setSize worked fine during will-resize event.

Testcase Gist URL

https://gist.github.com/ccc3e3fa4f724b5d717d9fc8f9c8dfe2

Additional Information

I suspect that the new behavior is caused by the following PR:

#33288

My application has some behavior implemented for controlling the minimal width and height in combination with the zoom factor. This is now broken and resizing freezes the resizing when the minimal width or height is reached. The setSize I use to continue resizing for the width/height where the limit isn't reached yet. It looks like the new behavior in Electron 17.4.0 is delaying the setSize until resize is done which breaks the behavior of my application.

[mlaurencin]

Thanks for reporting this and helping to make Electron better!

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

I'm adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a follow-up comment.

[WilfredC64]

I've added a testcase now: https://gist.github.com/ccc3e3fa4f724b5d717d9fc8f9c8dfe2

With the example you can clearly see the different behavior between Electron version 17.3.1 and 17.4.0 when you resize the window to the predefined minimal size on Windows OS.

[meredith-ciq]

We have a very similar issue with changes made under will-resize with prevent default are not being applied until mouse-up. In our case we want to prevent the resize and then make our own resize via setBounds; currently the window will jump to the final position on mouse-up with no visual indication that the window is being resized. I see that there is a potential fix for this issue, but it seems like setBounds will still be blocked in this case.

There are a couple of reasons why we need to do our own resize:

• We maintain collections of windows as a group and when a window in a group is resized we need to resize the other windows in the group in relation to the resized window. Triggering a setBounds on only the other windows would not be sufficient in this case as we need all windows' edges to stay visibly aligned which requires more precise control.
• When a window is resized from the top/left edge the opposite edge can visibly move a few pixels, we do our own calculations to work around that issue.

[codebytere]

@meredith-ciq setSize calls setBounds - my PR should address your case as well :)

[meredith-ciq]

@codebytere Ah my mistake then. I appreciate the update!

[WilfredC64]

I just tested the issue but now in Electron version 19.0.0 where the issue should also be fixed. Unfortunately the issue is not fully solved. If you resize both width and height together then the behavior is different than expected. I expect from the testcase that I provided that when the limit of the width is reached that the height can still be resized. Also the other way around, when the limit of the height is reached, the width can still be resized. Now the resizing is stopping when one of the limits is reached. In Electron version 17.3.1 this was working fine.

Can you please check and reopen the issue?

[WilfredC64]

I've investigated the issue a bit more and it appears that the setSize method doesn't have any effect now even with the event.preventDefault in the will-resize event. I expect that when you call the setSize method inside the will-resize method in combination of using preventDefault that it will set the size immediately, just like in Electron version 17.3.1.

[meredith-ciq]

I've also tested this for our case where we need to fully overwrite a resize action and the window now no longer resizes at all. SetBounds returns at the top if is_resizing_ is true, it seems like modifying pending_bounds_change_ wouldn't help in that case unless you can rely on the native resize action. Here is a simplified codeblock of what we need to do (I'm also happy to move my case to a new issue if that would be easier):

mainWindow.on('will-resize', (event, newBounds) => {
    // make changes to newBounds as needed
    event.preventDefault();
    mainWindow.setBounds(newBounds);
}