CODEWITHSUNDEEP
swiftmacosnswindow
Jim B.
Jim B.

Reputation: 4714

Resetting MacOS Window Backing Store

I'm building a macOS app that has a custom window (inheriting from NSWindow), with, among other things, a custom way of resizing it.

In the process of writing and debugging the resize code, I accidentally resized the window to an arbitrarily large value. No problem, I'm thinking. I just reverted the code to what had been working.

But now I'm getting this error before the window can even load:

2020-08-08 08:22:22.777588-0700 MyApp[1679:21967] -[<_NSViewBackingLayer: 0x600000c86220> display]: Ignoring bogus layer size (57500.000000, 57500.000000), contentsScale 2.000000, backing store size (115000.000000, 115000.000000)

My window is 300x300 pixels. Somehow macOS decided to make a backing store for me that is 115000x115000. This state survives a reboot. Ugh.

I have a workaround, which is to specifically set a new identifier in the .xib. So it looks to me like the system is committed to maintaining state for my window based on the id.

Instead of accumulating a bunch of state whenever I have a bug in my code, I'd much rather fix the root cause.

Where is this state being held? Is there any way to reset it?

Upvotes: 1

Views: 235

Answers (1)

Ken Thomases
Ken Thomases

Reputation: 90671

The "backing store" is a red herring. The issue is simply the saved size of the window.

You can maybe fix this by doing:

defaults delete <your app's bundle ID> "NSWindow Frame <you window's autosave name>"

If you don't mind nuking all of your app's preferences, you can just do:

defaults delete <your app's bundle ID>

Alternatively, you may need to delete your app's window restoration saved state. For a non-sandboxed app, that would be in ~/Library/SavedApplicationState/<your app's bundle ID>.savedState. For a sandboxed app, it's in the app's container at ~/Library/Containers/<your app's bundle ID>/Data/Library/SavedApplicationState/<your app's bundle ID>.savedState.

Upvotes: 1

Related Questions