Matlab R2022a freezes on macOS Monterey 12.5.1 when closing a figure

Matlab R2022a frequently, unpredictably becomes unresponsive when closing a figure (command or "X" GUI) since upgrading to R2022a on Monterey with multiple screens. Gernerally recovers after a few minutes, but it is usually faster to force quit and restart. Launching Matlab from a command terminal these days, which seemed to help with this problem for a while.

[Why Why]

C'mon, following the official answer, it's easy, all you have to do is uninstall all the other softwares on your computer. Isn't that what you expect from such expensive software?

Answer 1

[Daniel Calbick]

TL ; DR -- add this line to your startup.m file:

set(groot, 'defaultFigureCloseRequestFcn',@(src,evt) delete(src));

Hopefully this is the best place to post this as it was the first hit on google when I typed "figure crashing matlab macOS." I was really hoping this issue was going to go away with the introduction of native arm64 (apple sillicon) implementation of 2023b—however much to my chagrin, I think it happened more, and more catastophically at that.

BUT, I finally found a solution that has been working well for me! (it seems obvious now and I wish I did it years ago)

So, I was having the same isue with the 'x' button in the figure GUIs completely crashing MATLAB, and that has been a think since probably R2018 or thereabouts. To fix it I add the line I wrote above to the startup.m file (a file that matlab looks for in its saved path and will exicute upon launching) that re-associates this button with the command close(gcf). Haven't had a problem since (knock on wood).

[Enrico Onofri]

I got the same problem recently. I realized that Matlab worked fine until a week ago. At that time I discovered the nice tool "zoom" on the Mac (under 'accessibility"). When zoom is disabled the problem disappeared!

Notice that this happens on a M1 macbook running Sonoma. On an older Mac book pro with Ventura Zoom can be used with no harm on Matlab!

E.Onofri

[Jeroen Pröpper]

Thanks this worked perfectly

[Sanduo]

Thank you very much for the code, it now closes Figure properly.

[bader]

Thanks for the tip - however, when I did this, I was able to close figures but I would get a warning:

Warning: A callback recursively calls CLOSE. Use DELETE to prevent this message.

Fixed it by having the following adjustment to the line you posted in startup.m:

set(groot, 'defaultFigureCloseRequestFcn', 'delete(gcf)');

[RODOLFO]

I placed the file, but now when I open MATLAB, it remains in an infinite loading state and I'm forced to force quit

[Daniel Calbick]

@rodolfo, what did you actually put into your startup.m file?

Answer 2

[Kannan]

The problem you are facing seems to be caused by apps trying to use the Accessibility API to communicate with other applications and how MATLAB responds to it. You will have to disable the accessibility API for that app that is triggering this 'bug' in MATLAB and causing it to hang. Please refer to the answer posted here: https://www.mathworks.com/matlabcentral/answers/480796-not-responding-on-startup-macos-mojave.

[Dirk]

Unfortunately not. I have no apps selected for allowing Accessibility control.

[Javen]

Why I need to disable myself to cover fault for Matlab? Why Mathwork think its app can rule all other apps?

[Walter Roberson]

@Javen

What leads you to understand that the problem is caused by Mathworks, and not by Apple ?

[Javen]

Hi @Walter Roberson.

I was not intended to be angry at Mathworks, but the situation is:

1. many users reported this issue since release of MATLAB 2019, and there is no official respond, if there is any, it asks user to disable any other app that uses accessibility api.
2. no other app I have used has this issue. Which includes: native applications using only SwiftUI, using QT framework, using Electron or Flutter framework.

If this is caused by Apple, I apollogize for what I am saying. But we need a clear explaination why this will happen.

[Walter Roberson]

@Javen

See for example https://github.com/rxhanson/Rectangle/issues/912 about Chromium. Applications known to trigger the problem for Chromium (Chrome) users include

• CleanShot
• Dragon
• Grammarly
• Magnet
• Punto
• Xnapper

One person posted there that,

The problem is, some popular apps like Grammarly will constantly be reactivating the AXEnhancedUserInterface because that's the only way for them to access browser elements via the Accessibility API.

One person explained

What's going on here: "AXEnhancedUserInterface was enabled, will disable before resizing" refers to a weird hidden setting of macOS that can be toggled per application. If it is enabled, then window move/resize will be animated. This breaks Rectangle's move/resize behavior because Rectangle issues resize/move/resize per command, and the subsequent calls will terminate the prior one early when animation takes place, resulting in incorrect sizes/locations.

I certainly do not follow all of the implications, but that is hinting to me that applications that monitor resize events for their windows can possibly have this problem.

So you have applications that have an interest in examining the contents of windows (nominally for accesibility purposes), but it looks like a feedback loop of some sort can be created

The change was on the Apple side, not on the Mathworks side.

[Javen]

If you have dig more into the issue, you will understand this is not caused by this problem. AXEnhancedUserInterface is never enabled for MATLAB and such log will not show up in Rectangle or similar apps.

MATLAB's is not working correctly not only with Window management app, but also other apps that uses accessibility API.

And clearly from your respond, Mathworks is aware of this issue and they reject to fix this because this "may" caused by Apple and doesn't want to apply a fix for it although it affects users experience.

I am aware that engineers are busy doing computation related development and I am thankful that Mathworks provides new features to make students and researchers work more fluent than ever before. It's just I don't understand why ignore this specific issue.

[Walter Roberson]

@Javen

And clearly from your respond, Mathworks is aware of this issue

I do not work for Mathworks. Sometimes they tell me the reasons they do things, sometimes they do not.

The point of my posting is that there are other applications (not just MATLAB) having response delay and freezing problems due to the accessibility interface, that it is not only a MATLAB problem, that generally speaking such problems arose due ot changes at the Apple side.

Apple is notoriously stubborn about their changes, so likely the resolution is going to have to be Mathworks finding a way to work around the problem that Apple introduced, rather than Apple changing something on their end.