UPDATE: The bug described below is fixed in macOS 10.12.4 and the workaround described is no longer necessary (except for backward compatibility).
In a recent macOS project I have an NSTextField that contains text with tab characters in order to display a data table. (The text is an NSAttributedString to which I apply an NSParagraphStyle with its tabStops property set to an array containing a number of right-aligned NSTextTabs.)
The text field was drawn as intended (with the text aligned to the tab stops) before upgrading to 10.12.2. After upgraded, the text was no longer aligned to the tab stops, and when using monospacedDigitSystemFont there were cosmetic glitches displayed as well:
Under time pressure for a release, I implemented the workaround of replacing the NSTextField with an NSTextView. (I did this dynamically since it is not obvious how to create “bare” NSTextViews in Xcode’s Interface Builder.) Using an NSTextView I was able to get the data table to display as I had intended.
When writing up this bug (#29758498; Radar, Open Radar) I tried to create a simple test case that would illustrate the issue, but on my first try to recreate the problem from scratch, the issue didn’t appear. Puzzled, I copied the code and .xib file from my application into the test project, and was able to reproduce the issue.
By examining the text of the .xib files, I discovered that my newly created .xib file has a content view with wantsLayer=”YES”, and in this case the NSTextField works as intended under 10.12.2; but the .xib file from my application (which was created before Xcode 8 was released) did not have a layer set on the content view, and this did not work under 10.12.2 (although it had worked fine on 10.12.1 and earlier). Setting a layer on the application’s window’s content view (in the View Effects tab of the Assistant Editor in Xcode) was enough to fix the issue and make the table display as intended:
(Yes, bridge players, those point counts are bogus; my test program is generating random values to insert into the table.)
My wider questions are:
- What happened? We know there were a lot of graphic updates in 10.12.2, but it’s odd that the problem only occurs with the system font. I haven’t investigated whether the font file itself has changed.
- I can’t believe I’m the only person that’s run into this (although my usual googling produced no other hits). Is this really an uncommon case? Or is this a(nother) gap in Apple’s test suite?
- If Apple is expecting that the default case for content views is to have wantsLayer set, then it should certainly make this more widely known. I couldn’t find any references to this issue in the AppKit release notes.
Followup:
On January 9, 2017, my bug report was closed as a duplicate of another bug.
On January 10 the original bug was also closed. Unfortunately I do not know why (e.g. was it fixed, was it marked “won’t fix”, or what).
The problem is still present in 10.12.3; the workaround (adding wantsLayer to the window’s content view) continues to work.
Further followup: The problem has been fixed in 10.12.4; my test program now behaves correctly even without the workaround in place.