NSWindow warning in Yosemite
Sample app logs this warning:
2014-06-12 20:30:29.941 SampleApp[3067:24973] NSWindow warning: adding an unknown subview: <INTitlebarContainer: 0x100236a80>
2014-06-12 20:30:29.942 SampleApp[3067:24973] Call stack:
(
0 AppKit 0x00007fff8e18d4d3 -[NSThemeFrame addSubview:] + 81
1 AppKit 0x00007fff8db84464 -[NSView addSubview:positioned:relativeTo:] + 211
2 SampleApp 0x000000010000fbb5 -[INAppStoreWindow _createTitlebarView] + 325
3 SampleApp 0x000000010000d931 -[INAppStoreWindow _doInitialWindowSetup] + 1169
4 SampleApp 0x000000010000adf7 -[INAppStoreWindow initWithContentRect:styleMask:backing:defer:] + 215
5 AppKit 0x00007fff8daecd12 -[NSWindowTemplate nibInstantiate] + 567
6 AppKit 0x00007fff8dac190b -[NSIBObjectData instantiateObject:] + 309
7 AppKit 0x00007fff8dfac491 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 452
8 AppKit 0x00007fff8dab60f0 loadNib + 384
9 AppKit 0x00007fff8e02b6b0 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 313
10 AppKit 0x00007fff8dab57c5 -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 201
11 AppKit 0x00007fff8dab5591 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 344
12 AppKit 0x00007fff8dab1609 NSApplicationMain + 605
13 SampleApp 0x00000001000014c2 main + 34
14 SampleApp 0x0000000100001494 start + 52
15 ??? 0x0000000000000003 0x0 + 3
)
2014-06-12 20:30:30.042 SampleApp[3067:24973] NSWindow warning: adding an unknown subview: <INWindowButton: 0x10013ed40>
2014-06-12 20:30:30.043 SampleApp[3067:24973] Call stack:
(
0 AppKit 0x00007fff8e18d4d3 -[NSThemeFrame addSubview:] + 81
1 SampleApp 0x000000010000c53e -[INAppStoreWindow setCloseButton:] + 750
2 SampleApp 0x0000000100001f36 -[SampleAppAppDelegate setupCloseButton] + 710
3 SampleApp 0x0000000100001c24 -[SampleAppAppDelegate applicationDidFinishLaunching:] + 1876
4 CoreFoundation 0x00007fff89366a5c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
5 CoreFoundation 0x00007fff892545c4 _CFXNotificationPost + 3140
6 Foundation 0x00007fff93736761 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
7 AppKit 0x00007fff8dada22b -[NSApplication _postDidFinishNotification] + 291
8 AppKit 0x00007fff8dad9f66 -[NSApplication _sendFinishLaunchingNotification] + 191
9 AppKit 0x00007fff8dad6e16 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 574
10 AppKit 0x00007fff8dad6855 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 244
11 Foundation 0x00007fff93756478 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 290
12 Foundation 0x00007fff937562e9 _NSAppleEventManagerGenericHandler + 102
13 AE 0x00007fff9281d1ec _Z20aeDispatchAppleEventPK6AEDescPS_jPh + 531
14 AE 0x00007fff9281cf69 _ZL25dispatchEventAndSendReplyPK6AEDescPS_ + 31
15 AE 0x00007fff9281ce73 aeProcessAppleEvent + 295
16 HIToolbox 0x00007fff89c03836 AEProcessAppleEvent + 56
17 AppKit 0x00007fff8dad2d43 _DPSNextEvent + 2310
18 AppKit 0x00007fff8dad1ff9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 139
19 AppKit 0x00007fff8dac5fe3 -[NSApplication run] + 594
20 AppKit 0x00007fff8dab1a9e NSApplicationMain + 1778
21 SampleApp 0x00000001000014c2 main + 34
22 SampleApp 0x0000000100001494 start + 52
23 ??? 0x0000000000000003 0x0 + 3
)
2014-06-12 20:30:30.052 SampleApp[3067:24973] NSWindow warning: adding an unknown subview: <INWindowButton: 0x10033b7e0>
2014-06-12 20:30:30.053 SampleApp[3067:24973] Call stack:
(
0 AppKit 0x00007fff8e18d4d3 -[NSThemeFrame addSubview:] + 81
1 SampleApp 0x000000010000c86e -[INAppStoreWindow setMinimizeButton:] + 750
2 SampleApp 0x0000000100002236 -[SampleAppAppDelegate setupMinimizeButton] + 710
3 SampleApp 0x0000000100001c37 -[SampleAppAppDelegate applicationDidFinishLaunching:] + 1895
4 CoreFoundation 0x00007fff89366a5c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
5 CoreFoundation 0x00007fff892545c4 _CFXNotificationPost + 3140
6 Foundation 0x00007fff93736761 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
7 AppKit 0x00007fff8dada22b -[NSApplication _postDidFinishNotification] + 291
8 AppKit 0x00007fff8dad9f66 -[NSApplication _sendFinishLaunchingNotification] + 191
9 AppKit 0x00007fff8dad6e16 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 574
10 AppKit 0x00007fff8dad6855 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 244
11 Foundation 0x00007fff93756478 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 290
12 Foundation 0x00007fff937562e9 _NSAppleEventManagerGenericHandler + 102
13 AE 0x00007fff9281d1ec _Z20aeDispatchAppleEventPK6AEDescPS_jPh + 531
14 AE 0x00007fff9281cf69 _ZL25dispatchEventAndSendReplyPK6AEDescPS_ + 31
15 AE 0x00007fff9281ce73 aeProcessAppleEvent + 295
16 HIToolbox 0x00007fff89c03836 AEProcessAppleEvent + 56
17 AppKit 0x00007fff8dad2d43 _DPSNextEvent + 2310
18 AppKit 0x00007fff8dad1ff9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 139
19 AppKit 0x00007fff8dac5fe3 -[NSApplication run] + 594
20 AppKit 0x00007fff8dab1a9e NSApplicationMain + 1778
21 SampleApp 0x00000001000014c2 main + 34
22 SampleApp 0x0000000100001494 start + 52
23 ??? 0x0000000000000003 0x0 + 3
)
2014-06-12 20:30:30.057 SampleApp[3067:24973] NSWindow warning: adding an unknown subview: <INWindowButton: 0x100340510>
2014-06-12 20:30:30.058 SampleApp[3067:24973] Call stack:
(
0 AppKit 0x00007fff8e18d4d3 -[NSThemeFrame addSubview:] + 81
1 SampleApp 0x000000010000cb9e -[INAppStoreWindow setZoomButton:] + 750
2 SampleApp 0x0000000100002536 -[SampleAppAppDelegate setupZoomButton] + 710
3 SampleApp 0x0000000100001c4a -[SampleAppAppDelegate applicationDidFinishLaunching:] + 1914
4 CoreFoundation 0x00007fff89366a5c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
5 CoreFoundation 0x00007fff892545c4 _CFXNotificationPost + 3140
6 Foundation 0x00007fff93736761 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
7 AppKit 0x00007fff8dada22b -[NSApplication _postDidFinishNotification] + 291
8 AppKit 0x00007fff8dad9f66 -[NSApplication _sendFinishLaunchingNotification] + 191
9 AppKit 0x00007fff8dad6e16 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 574
10 AppKit 0x00007fff8dad6855 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 244
11 Foundation 0x00007fff93756478 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 290
12 Foundation 0x00007fff937562e9 _NSAppleEventManagerGenericHandler + 102
13 AE 0x00007fff9281d1ec _Z20aeDispatchAppleEventPK6AEDescPS_jPh + 531
14 AE 0x00007fff9281cf69 _ZL25dispatchEventAndSendReplyPK6AEDescPS_ + 31
15 AE 0x00007fff9281ce73 aeProcessAppleEvent + 295
16 HIToolbox 0x00007fff89c03836 AEProcessAppleEvent + 56
17 AppKit 0x00007fff8dad2d43 _DPSNextEvent + 2310
18 AppKit 0x00007fff8dad1ff9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 139
19 AppKit 0x00007fff8dac5fe3 -[NSApplication run] + 594
20 AppKit 0x00007fff8dab1a9e NSApplicationMain + 1778
21 SampleApp 0x00000001000014c2 main + 34
22 SampleApp 0x0000000100001494 start + 52
23 ??? 0x0000000000000003 0x0 + 3
)
As far as I can tell, this is harmless (everything seems to work), but it would be nice to figure out a way to fix or suppress this warning.
Probably we can use NSWindowMaskFullScreenContentView or whatever it's called. Also, CoreUI rendering still draws 10.9'ish in 10.10 and [NSWindow coreUIRenderer](while it still exists) returns nil. Might just be a bug at this point though; some system apps in 10.10 have different title bars than others.
Yes it is harmful: the added subview is in fact not added! Note that this bug only occurs when built on 10.10. Not when built on 10.9 (and ran on 10.10).
First screenshot is code built on 10.10

vs
Second screenshot is code built on 10.9, ran on 10.10

Are you sure you are running the latest version of Yosemite? I remember seeing an identical rendering artifact in the first couple previews; it's gone as of the third.
Also, your screenshots don't actually seem to indicate that a subview is missing, so I'm a bit confused here.
(I'm ahugele, sorry for mislogin) Yes it's Yosemite beta 4 (14A298i). You're right, I quickly assumed the custom subview was missing. The exact message is "NSWindow warning: adding an unknown subview: INMovableByBackgroundContainerView: 0x100237440" followed by the stack trace.
Anyway, the rendering is different as I of course want a full black background, even around the title. Note that I'm using a custom drawing block (because the black black background is in fact a gradient)
I also get this warning on the latest version of Yosemite.
Getting the warning in the public beta (14A299l), and getting the title field rendering issue that @ahugele showed above (though, for me, it only happens about half of the time I open the window!).
I have two different windows. The first one sees this problem but the second one doesn't. They use identical initialisation code. anyone got a workaround?
It sounds to me like more than a simple warning, see "Applications doing this will need to fix this problem".
https://developer.apple.com/library/prerelease/mac/releasenotes/AppKit/RN-AppKit/
New since WWDC seed: NSWindow has never supported clients adding subviews to anything other than the contentView. Some applications would add subviews to the contentView.superview (also known as the border view of the window).
NSWindow will now log when it detects this scenario: "NSWindow warning: adding an unknown subview:".
**Applications doing this will need to fix this problem**, as it prevents new features on 10.10 from working properly. See titlebarAccessoryViewControllers for official API.
Hm. I wonder if INAppStoreWindow could be re-engineered as a shim for new Yosemite NSWindow APIs...
That's not really a suitable workaround as you can only add accessory views to the right and bottom of the titlebar (see NSTitlebarAccessoryViewController.h - layoutAttribute). Maybe this will change in the GM.
What the AppKit RN says is a little depressing. It officially states that the INAppStoreWindow way to customize the title bar is not supported. And NSTitlebarAccessoryViewController is not a replacement at this time.
I suggest we all radar that to apple.
Upgraded to Yosemite and encountering this problem here too now. Is there any fix in sight? If not I might have to stop using this otherwise nice control.
Also echoing that we're using InAppStoreWindow and running into the same issue.
Same here.
I have a production Yosemite app using this, and while the warning is logged, it doesn't seem to affect the functionality (at least for now). There's no workaround that I can see, so I'll file a radar but it's unlikely that they're going to reverse that decision.
I'd be very interested to know if any apps get bounced because of this.
@gregucsd My app got approved a few days ago.
There's no workaround that I can see, so I'll file a radar but it's unlikely that they're going to reverse that decision.
Why would (or should) they? We should simply rewrite INAppStoreWindow to use the proper APIs...
There are no proper APIs to do what INAppStoreWindow does. They added an NSWindow API for title bar accessory view controllers to compensate for this change, but it's nowhere near sufficient to implement INAppStoreWindow.
@indragiek Great. Thank you for confirming. @jakepetroules I haven't seen "proper" APIs for this. In my estimation it means recreating all of the window title / tool -bar functionality in a borderless window. I would've thought there would be a standard way to do this but looking through Apple's apps (iTunes, xCode, Calendar, etc) they all have different looks that obviously have very different requirements and backing to support.
This is how WebKit "solved" the issue: http://trac.webkit.org/changeset/170980/trunk/Source/WebKit/mac/WebCoreSupport/WebInspectorClient.mm
I tried adding this to INAppStoreWindow.m:
@interface NSView (AppKitDetails)
-
(void)_addKnownSubview: (NSView *)subview;
-
(void)_addKnownSubview:(NSView *)aView positioned:(NSWindowOrderingMode)place relativeTo:(NSView *)otherView; @end
if ([self.themeFrameView respondsToSelector: @selector(_addKnownSubview:positioned:relativeTo:)]) { [self.themeFrameView _addKnownSubview: container positioned: NSWindowBelow relativeTo: firstSubview]; } else { [[self themeFrameView] addSubview:container positioned:NSWindowBelow relativeTo:firstSubview]; }
which mostly works and no longer produces a warning. However, the container seems not to be positioned correctly or so. I see my own subview I added, but not, e.g., the traffic lights.
That's private API, so you won't be able to submit to the Mac app store if you use that method.
here is the solution https://github.com/guolai/mac-titleBar
If you only intent to have a custom title bar height on Yosemite: My current work-around is to check if it's running on Yosemite at runtime. If not, use INAppStoreWindow as usual.
Otherwise use a normal NSWindow, and add a NSTitlebarAccessoryViewControllerto the NSWindow's title bar using addTitleBarAccessoryViewController:, which controls an empty dummy view with the desired height.
Not feasible if you create the main window in your main xib (as you have to set the window class there).
Mike
www.soft-gems.net
I published WAYWindow, which aims to provide an interface similar to INAppStoreWindow, but exclusively for OS X Yosemite applications. Hope I can help some guys with it.
@mike-lischke You're right. One solution could be to create the NSWindow at runtime (either NSWindow, WAYWindow or INAppStoreWindow) and only define a view in the XIB, instead of a whole window, which will then be added to the window's contentView.
@raffael This is pretty cool. Thanks for that. What about adding something that can be used to switch between WAYWindow and INAppStoreWindow depending on the app kit we are running on? E.g. you could derive WAYWindow from INAppStoreWindow and disable functionality that only works on Yosemite if the app runs on older OSX versions. That would be awsome!
@mike-lischke
I had the same thoughts, but I wanted a separate repo for this.
So I just published WAYAppStoreWindow, which does the following:
At runtime it detects whether the app is running on OS X 10.10 or greater, and if so, the class implementation will be switch to WAYWindow. Otherwise, INAppStoreWindow will be used.
This is an ugly hack, and I haven't tested it yet profoundly.
However, setting a custom title bar height, hiding the window title and centering the traffic lights works beautifully.
Well, it's not that ugly and works pretty well (after applying my changes to avoid WAYWindow to crash). I recommend everybody here to try this out, even though there's still a layout problem (reported already).
We just updated the repo (WAYAppStoreWindow) with fixes for the mentioned bugs. Thanks, mike!
@raffael Thanks for WAYWindow! However, I'm also using other properties of INAppStoreWindow like verticallyCenterTitle, titleFont and titleTextColor, which are not supported in WAYWindow right now. Any plan to support them too?
@ishuo Thanks! Some of INAppStoreWindow's features are not supported (yet?) by WAYWindow. It's a starting point. For our projects it was important to have at least a window instance with customizable titlebar height and traffic lights layout. If you use WAYAppStoreWindow instead of WAYWindow directly, you'll get some decent warnings in the console, instead of exceptions for unrecognized selectors.
We might add more features in future!
I'm currently looking for a way to add a Subview to the Window Titlebar on Yosemite, so if anyone has an idea how to do it the right way, would be great if I could get an answer over at Stackoverflow. I am looking for the best approach which is less likely to break in the future… (I'm asking this here because here seem to be a lot people to have experience with it and INAppStoreWindow could benefit of a solution for this too)
Note that NSTitlebarAccessoryViewController with right layout actually adds a view that spans to the full width of the titlebar, not only to the right of then window controls, but there is a problem with the height (see linked SO above)
How can i use WAYAppStoreWindow with backward compatibility to OS x10.9.5?
utkarshagutpa, pls don't hijack issues for support questions. You could open an own issue or ask on Stackoverflow. WAYAppStoreWindow automatically handles compatibility by replacing the actual class that is instantiated depending on the OS.
@interface NSView (AppKitDetails)
- (void)_addKnownSubview:(NSView *)aView positioned:(NSWindowOrderingMode)place relativeTo:(NSView *)otherView; @end
bool isTenTenPlus;
-
(NSButton *)_windowButtonToLayout:(NSWindowButton)defaultButtonType orUserProvided:(NSButton *)userButton { NSButton *defaultButton = [self standardWindowButton:defaultButtonType]; if (userButton) { [defaultButton setHidden:YES]; defaultButton = userButton; } else if ([defaultButton superview] != [self themeFrameView]) { [defaultButton setHidden:NO]; }
if ( true == isTenTenPlus ) { [self.titleBarView addSubview:defaultButton]; }
return defaultButton; }
-
(void)initialize { isTenTenPlus = YES == [[[[NSWindow new] contentView] superview] respondsToSelector:@selector(_addKnownSubview:positioned:relativeTo:)]; } //
-
(void)_layoutTrafficLightsAndContent .... // for horizontal don't touch origin if ( false == isTenTenPlus ) { closeFrame.origin.y = buttonOrigin; minimizeFrame.origin.y = buttonOrigin; zoomFrame.origin.y = buttonOrigin; }
-
(void)_createTitlebarView .... f ( true == isTenTenPlus ) { [[self themeFrameView] _addKnownSubview:container positioned:NSWindowBelow relativeTo:firstSubview]; [[[[self.contentView superview] subviews] lastObject] removeFromSuperview];// I'm use titlebar drawing block and remove NSTitlebarContainerView } else { [[self themeFrameView] addSubview:container positioned:NSWindowBelow relativeTo:firstSubview]; }
Hi guys, has anyone seen any solutions to this? I too need some of the INAppStoreWindow properties so usingWayWindow isn't feasible at the moment... :(
Same issue here. Would be great if it can be fixed.