bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Gerd Möllmann]

On macOS 14, Emacs occasionally prints to stderr

  2024-08-03 11:45:26.785586+0200 emacs[97956:1226150] [miscellany] CLIENT ERROR: TUINSRemoteViewController does not override -viewServiceDidTerminateWithError: and thus cannot react to catastrophic errors beyond logging them

Some digging on the Internet reveals that this is in the end caused by
an API change in NSView in macOS 14.

  https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#NSView

  /* Defaults to NO on macOS 14 and later. Defaults to YES on previous releases. Note some classes (like NSClipView) set their own default values differently than NSView itself.
   */
  @property BOOL clipsToBounds API_AVAILABLE(macos(10.9));

Proposed fix for emacs-30 (minus the igc stuff):

1 file changed, 4 insertions(+)
src/nsterm.m | 4 ++++

modified   src/nsterm.m
@@ -8069,6 +8069,10 @@ - (instancetype) initFrameFromEmacs: (struct frame *)f
   emacsframe = igc_xalloc_raw_exact (1);
 #else
   emacsframe = xzalloc (sizeof *emacsframe);
+#endif
+#ifdef NS_IMPL_COCOA
+  if (NSAppKitVersionNumber >= NSAppKitVersionNumber14_0)
+    self.clipsToBounds = YES;
 #endif
   windowClosing = NO;
   processingCompose = NO;

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Proposed fix for emacs-30 (minus the igc stuff):

Pushed to master instead, and closing.

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Mattias Engdegård]

After the recent changes to nsterm.m, I get the warning

../../emacs/src/nsterm.m:8077:9: warning: instance method '-setClipsToBounds:' not found (return type defaults to 'id') [-Wobjc-method-access]
  [self setClipsToBounds: YES];
        ^~~~~~~~~~~~~~~~
../../emacs/src/nsterm.h:466:12: note: receiver is instance of class declared here
@interface EmacsView : NSView <NSTextInput, NSTextInputClient, NSWindowDelegate>
           ^

when compiling (on macOS 11.7.10). Would you please help fixing that?

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> After the recent changes to nsterm.m, I get the warning
>
> ../../emacs/src/nsterm.m:8077:9: warning: instance method '-setClipsToBounds:' not found (return type defaults to 'id') [-Wobjc-method-access]
>   [self setClipsToBounds: YES];
>         ^~~~~~~~~~~~~~~~
> ../../emacs/src/nsterm.h:466:12: note: receiver is instance of class declared here
> @interface EmacsView : NSView <NSTextInput, NSTextInputClient, NSWindowDelegate>
>            ^
>
> when compiling (on macOS 11.7.10). Would you please help fixing that?

Can you please check with what I just committed?

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Mattias Engdegård]

5 aug. 2024 kl. 17.27 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Can you please check with what I just committed?

Thank you but that doesn't make a difference -- it's a static, not dynamic, warning.
Instead we could put it inside

#if MAC_OS_X_VERSION_MAX_ALLOWED >= 140000
..
#endif

which works here but I may be confusing the version macros.

More to the point, is the [self setClipsToBounds: YES] line actually required with older OS versions? If so, maybe it's just a matter of declaring the property somehow since it's supposed to exist even if the declaration was only made public in v14, but not sure if that is even possible.

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 5 aug. 2024 kl. 17.27 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Can you please check with what I just committed?
>
> Thank you but that doesn't make a difference -- it's a static, not dynamic, warning.
> Instead we could put it inside
>
> #if MAC_OS_X_VERSION_MAX_ALLOWED >= 140000
> ..
> #endif
>
> which works here but I may be confusing the version macros.
>
> More to the point, is the [self setClipsToBounds: YES] line actually
> required with older OS versions? If so, maybe it's just a matter of
> declaring the property somehow since it's supposed to exist even if
> the declaration was only made public in v14, but not sure if that is
> even possible.

I also don't know what's the right thing to do is here. One could use
the #ifdef as you showed, but then an Emacs compiled on 13.x won't do
what it should when run on 14.x. (I gather that it would otherwise run
fine.)

A runtime check with NSAppKitVersionNumber would work, if one copies the
float values for the version from NSApplication.h, and compares with
that. One has to copy the version number if one compiles on older
versions where the constant is not defined (can be either a define or a
const double in 14.5 here).

What a mess. Hopefully Alan has some advice.

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Alan Third]

On Mon, Aug 05, 2024 at 08:27:55PM +0200, Gerd Möllmann wrote:
> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
> 
> > 5 aug. 2024 kl. 17.27 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
> >
> >> Can you please check with what I just committed?
> >
> > Thank you but that doesn't make a difference -- it's a static, not dynamic, warning.
> > Instead we could put it inside
> >
> > #if MAC_OS_X_VERSION_MAX_ALLOWED >= 140000
> > ..
> > #endif
> >
> > which works here but I may be confusing the version macros.
> >
> > More to the point, is the [self setClipsToBounds: YES] line actually
> > required with older OS versions? If so, maybe it's just a matter of
> > declaring the property somehow since it's supposed to exist even if
> > the declaration was only made public in v14, but not sure if that is
> > even possible.
> 
> I also don't know what's the right thing to do is here. One could use
> the #ifdef as you showed, but then an Emacs compiled on 13.x won't do
> what it should when run on 14.x. (I gather that it would otherwise run
> fine.)

IIRC apps built on an older version of macOS generally run as though
they are on that version of macOS even when on a newer version.

> A runtime check with NSAppKitVersionNumber would work, if one copies the
> float values for the version from NSApplication.h, and compares with
> that. One has to copy the version number if one compiles on older
> versions where the constant is not defined (can be either a define or a
> const double in 14.5 here).
> 
> What a mess. Hopefully Alan has some advice.

The correct thing to do is only set this when compiling on v14 or
above, so the #ifdef is the right way to go.

FWIW, we have never guaranteed an executable compiled on one version
of macOS will work on any other version. At one time I put a fair bit
of effort into trying to get that working and it just turned into a
nightmare of #if's and runtime checks all over the place and made
maintenance far too hard.

Apple's approach would be that you *always* compile against the latest
version, and only support three versions back, or whatever, and that
way you can easily insert run-time checks as the API will always be
available at compile time, even if it's not there at runtime.

Emacs packagers generally build against multiple versions of macOS and
ship a bundle of multiple executables that are selected by a script at
runtime.

(Another approach, that I'd not recommend, would be to just put the
code in with no check whatsoever. A non-existent method will always
return nil at runtime, and just return a warning at compile time. This
means people compiling on older versions just have to live with
compiler warnings, but otherwise nothing should break.)
-- 
Alan Third

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Mattias Engdegård]

5 aug. 2024 kl. 21.16 skrev Alan Third <alan@idiocy.org>:

> The correct thing to do is only set this when compiling on v14 or
> above, so the #ifdef is the right way to go.

Thanks, I pushed something that at least silenced the compiler, but please verify that I didn't break anything.

But should I worry about the property not being set on my machine? If I understand the release notes:

> In macOS 14, AppKit is exposing the clipsToBounds property of NSView.
> 
> For applications linked against the macOS 14 SDK, the default value of this property is true. Apps linked against older SDKs default to false. Some classes, like NSClipView, continue to default to true. The change in defaults recognizes that it is vastly easier to reason about clipping a view’s descendants than it is to unclip a view’s ancestors.
> 
> Users can turn clipping back on by using the NSView.clipsToBounds setter or using the attributes inspector of a view in the Xcode interface builder.
> This property is available back to macOS 10.9. This availability is intended to allow code targeting older OSes to set this property to true without guarding the setter in an availability check. Setting this property to false on previous OSes may not work reliably.

correctly, then the property exists in older versions but is just not exposed -- is that a correct interpretation? So attempting to set it might actually work, even though the compiler warns? If so, would it be possible to declare it manually to please the compiler?

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Mattias Engdegård]

> correctly, then the property exists in older versions but is just not exposed -- is that a correct interpretation?

I can answer that partially from an experiment: yes, [self respondsToSelector:@selector(setClipsToBounds:)] returns true on an older version.

Of course this whole business only matters when Emacs is compiled on macOS<13 and then executed on ≥14 which probably isn't that important.

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Alan Third]

On Mon, Aug 05, 2024 at 09:46:09PM +0200, Mattias Engdegård wrote:
> > correctly, then the property exists in older versions but is just
> > not exposed -- is that a correct interpretation?
> 
> I can answer that partially from an experiment: yes, [self
> respondsToSelector:@selector(setClipsToBounds:)] returns true on an
> older version.

You may be running the latest version of xcode? IIRC that can affect
what's available. The whole thing is confusing.

-- 
Alan Third

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Gerd Möllmann]

Alan Third <alan@idiocy.org> writes:

> On Mon, Aug 05, 2024 at 09:46:09PM +0200, Mattias Engdegård wrote:
>> > correctly, then the property exists in older versions but is just
>> > not exposed -- is that a correct interpretation?
>> 
>> I can answer that partially from an experiment: yes, [self
>> respondsToSelector:@selector(setClipsToBounds:)] returns true on an
>> older version.
>
> You may be running the latest version of xcode? IIRC that can affect
> what's available. The whole thing is confusing.

Thanks Alan. I find it highly confusing, too.

Anyway, Mattias' #if worss here. 

bug#72440: 31.0.50; MacOS: TUINSRemoteViewController log message

[Alan Third]

On Mon, Aug 05, 2024 at 09:38:41PM +0200, Mattias Engdegård wrote:
> 5 aug. 2024 kl. 21.16 skrev Alan Third <alan@idiocy.org>:
> 
> > The correct thing to do is only set this when compiling on v14 or
> > above, so the #ifdef is the right way to go.
> 
> Thanks, I pushed something that at least silenced the compiler, but
> please verify that I didn't break anything.
> 
> But should I worry about the property not being set on my machine?
> If I understand the release notes:
> 
> > In macOS 14, AppKit is exposing the clipsToBounds property of NSView.
> > 
> > For applications linked against the macOS 14 SDK, the default
> > value of this property is true. Apps linked against older SDKs
> > default to false. Some classes, like NSClipView, continue to
> > default to true. The change in defaults recognizes that it is
> > vastly easier to reason about clipping a view’s descendants than
> > it is to unclip a view’s ancestors.
> > 
> > Users can turn clipping back on by using the NSView.clipsToBounds
> > setter or using the attributes inspector of a view in the Xcode
> > interface builder. This property is available back to macOS 10.9.
> > This availability is intended to allow code targeting older OSes
> > to set this property to true without guarding the setter in an
> > availability check. Setting this property to false on previous
> > OSes may not work reliably.
> 
> correctly, then the property exists in older versions but is just
> not exposed -- is that a correct interpretation? So attempting to
> set it might actually work, even though the compiler warns? If so,
> would it be possible to declare it manually to please the compiler?

Nothing should have changed on older machines. If it had you'd be
seeing the same messages as in the original bug report.

Looking at the docs at

https://developer.apple.com/documentation/appkit/nsview/4236466-clipstobounds?language=objc

it looks very much like we want to just set this to YES and forget
about it, but going by the examples they give we're unlikely to run
into any actual layout issues as we don't (intentionally) do any of
the things they talk about.

We have no reason to ever draw outside the bounds.

-- 
Alan Third