Trouble with NSTableViews in macOS 11.x


Sak Wathanasin
 

The tableviews in one of our apps is behaving strangely when running on macOS 11.x. I have managed to reproduce thsi with a simple test app. Essentially, the issue occurs if if I build using the 11.x SDK (ie using Xcode 12.2 or later) when running on 11.x.

What happens is that the table is shifted to the right when running on 11.x. This happens with both view-based and cell-based tables. For example, the frame for the (0,0) cell is

on 10.15: (1.0, 1.0, 116.0, 24.0)
on 11.2.3: (6.0, 1.0, 116.0, 24.0)

Even weirder, if I set the enclosing NSScrollView to "no borders" the frame is now

(16.0, 1.0, 116.0, 24.0)

AND the grid lines don't extend the full width of the table, AND the line after the last row isn't drawn (that's what got QA on to the case).

On 10.15, my test tables look like this - both tables the same except for the border, and both aligned left:

But on 11.x, it looks like this:

As you can see, the "no border" version is very different.

Looking at the release notes (https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-11), the only thing I could see that might be relevant is

NSScrollView
• When linked on macOS Big Sur 11 or later, an NSScrollViewwith automaticallyAdjustsContentInsets set to truewill continue to respect the safe-area insets of the window even when titlebarAppearsTransparent is set to true. For apps linked earlier than macOS Big Sur 11 NSScrollViewwill ignore the automatic insets when titlebarAppearsTransparent is set to true.

But my scrollviews have this turned off.

I haven't seen any reports of this issue so I assume I'm doing something very stupid. Any idea what? I can send the test project to anyone who has the time to look at it; it's tiny.

Many thanks for any help

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Shane Stanley
 

On 27 Mar 2021, at 6:46 am, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:

What happens is that the table is shifted to the right when running on 11.x.
Try adding this to your code at an appropriate point:

if (@available(macOS 11.0, *)) {
myTableView.style = NSTableViewStyleFullWidth;
}


--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Jon Gotow
 

I ran into this when updating all of my apps for Big Sur. You'd think the "Full Width" style would make the table, well, full width, but it doesn't. I think the solution was to set the tableview style to "Plain". 

 - Jon

On Fri, Mar 26, 2021 at 1:46 PM Sak Wathanasin <sw@...> wrote:
The tableviews in one of our apps is behaving strangely when running on macOS 11.x. I have managed to reproduce thsi with a simple test app. Essentially, the issue occurs if if I build using the 11.x SDK (ie using Xcode 12.2 or later) when running on 11.x.

What happens is that the table is shifted to the right when running on 11.x. This happens with both view-based and cell-based tables. For example, the frame for the (0,0) cell is

on 10.15: (1.0, 1.0, 116.0, 24.0)
on 11.2.3: (6.0, 1.0, 116.0, 24.0)

Even weirder, if I set the enclosing NSScrollView to "no borders" the frame is now

(16.0, 1.0, 116.0, 24.0)

AND the grid lines don't extend the full width of the table, AND the line after the last row isn't drawn (that's what got QA on to the case).

On 10.15, my test tables look like this - both tables the same except for the border, and both aligned left:

But on 11.x, it looks like this:

As you can see, the "no border" version is very different.

Looking at the release notes (https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-11), the only thing I could see that might be relevant is

NSScrollView
• When linked on macOS Big Sur 11 or later, an NSScrollViewwith automaticallyAdjustsContentInsets set to truewill continue to respect the safe-area insets of the window even when titlebarAppearsTransparent is set to true. For apps linked earlier than macOS Big Sur 11 NSScrollViewwill ignore the automatic insets when titlebarAppearsTransparent is set to true.

But my scrollviews have this turned off.

I haven't seen any reports of this issue so I assume I'm doing something very stupid. Any idea what? I can send the test project to anyone who has the time to look at it; it's tiny.

Many thanks for any help

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Sak Wathanasin
 



On 26 Mar 2021, at 22:46, Jon Gotow <gotow@...> wrote:

I ran into this when updating all of my apps for Big Sur. You'd think the "Full Width" style would make the table, well, full width, but it doesn't. I think the solution was to set the tableview style to "Plain". 



I had set the style to "full-width" in IB, but that had no effect. Let me give "plain" a shot.

Thanks for the suggestions,

Sak


Sak Wathanasin
 



On 26 Mar 2021, at 22:46, Jon Gotow <gotow@...> wrote:

I ran into this when updating all of my apps for Big Sur. You'd think the "Full Width" style would make the table, well, full width, but it doesn't. I think the solution was to set the tableview style to "Plain". 

Both "plain" and "fullwidth" sort of work; my mistake was using IB to set this property and it had no effect. When I set it in code (thanks, Shane!), I could see differences in behaviour. Both styles result in the gridlines being drawn from edge to edge. However,

1) with "fullwidth"
- the table is still indented (6 or 16 px as before)
- if the enclosing scrollview has borders, gridlines are drawn for empty rows
- if the scrollview has no borders, gridlines are not drawn for empty rows

2) with "plain"
- the table is no longer indented
- gridlines are not drawn for empty rows whether the scrollview has borders or not

We want gridlines on empty rows, but our tables are also borderless as the designers wanted the border around the table name label as well. Bascially, we want the 10.15 behaviour back. That it behaves differently depending on whether the enclosing scrollview is bordered or not doesn't feel right.

I guess it's worth raising a bug report with Apple and seeing what comes of it.

Thanks to everyone
Sak