macOS: Avoid redundant initial resize event

[madsmtm]

The NSViewFrameDidChangeNotification that we listen to is emitted when -[NSWindow setContentView] is called, since that sets the frame of the view as well.

So now we register the notification later, so that it's not triggered at window creation.

Together with #3912, this fixes #3235.

Part of #2640.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users

[kchibisov]

I wonder why we not compare the current size with the new size? Just moving the place where the size observer is being set doesn't sound like the right way to solve this(though it likely does solve this).

Just generally tracking the active size and comparing should generally reduce the amount of resizes we're sending to the user.

[madsmtm]

I wonder why we not compare the current size with the new size? Just moving the place where the size observer is being set doesn't sound like the right way to solve this(though it likely does solve this).

Just generally tracking the active size and comparing should generally reduce the amount of resizes we're sending to the user.

I know it may feel brittle, but (for once in AppKit) the behaviour here is actually well documented.

This documentation says:

The notification is not posted when you set the frame rectangle to the value it already has.

I.e. redundant resizes are already avoided by AppKit internally. The reason this wasn't considered a redundant resize before is because the view had size (0, 0) before being added to the window.

The documentation also says:

If the value of this property is currently false and and the frame has changed, changing the value to true causes the view to post a NSViewFrameDidChangeNotification notification immediately. This happens even when there has been no net change in the view’s frame rectangle.

Which also exactly describes the behaviour we avoid by registering the observer after setting postsFrameChangedNotifications.