Matlab 2025 and newer stalls in uigetfile

I have a long script that calls uigetfile twice to select files to operate on. The original script was written in 2011 and used a bunch of javascript calls to address Guide figures. I've removed these and replaced them with modern code, but there's probably still some legacy issues to be resolved.

In 2024a, the script runs just fine. However in 2025a or 2026a the script will run the first time after I load Matlab, but then will it stall the second time I run the script. It appears that this is a Matlab problem, rather than a script problem.

Here is the relevant section of the code:

% Get initial and final scans
[filename1,pathname1,~] = uigetfile({'*.ctw; *.itw'},'Pick Initial Scans',startdir,'MultiSelect','on');
[filename2,pathname2,filterindex2] = uigetfile({'*.ctw; *.itw'},'Pick Final Scans',pathname1,'MultiSelect','on');

When I run the script the second time, Matlab shows the first get window, but then it seems to go into an endless loop before the second window is shown. If I manually click "Stop" I get this error stack:

Operation terminated by user during matlab.ui.internal.dialog.MATLABBlocker/blockMATLAB (line 11)

In matlab.ui.internal.dialog.WebFileChooser/showDialog (line 98)

obj.blockMATLAB();

^^^^^^^^^^^^^^^^^

In uigetputfile_helper (line 50)

ufd.showDialog(dialog_filter, uigetputtype);

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In uigetfile (line 16)

[filename, pathname, filterindex] = uigetputfile_helper(0, varargin{:});

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In MyScript (line 259)

[filename1,pathname1,~] = uigetfile({'*.ctw; *.itw'},'Pick Initial Scans',startdir,'MultiSelect','on');

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What is going on here? Why is this new to 2025 or newer, and what can I do about it?

After I ran the script the first time, I created a separate script with only the following two lines:

startdir ='C:\';  
[filename1,pathname1,~] = uigetfile({'*.ctw; *.itw'},'Pick Initial Scans',startdir,'MultiSelect','on');

That script also stalls, and gives the same error stack. So apparently there is something in my code that's causing uigetfile to blow up. What could I possibly have done that would cause this?

[Torsten]

Contact support:

https://uk.mathworks.com/support/contact_us.html

[dpb]

Which OS?

As @Torsten, suggests, it's an official support request, probably to resolve, but just out of curiosity, what if you cut back to just the single

[filename1,pathname1,~] = uigetfile();

plain vanilla first, and then add parameters one at a time? Can you then isolate where it breaks, assuming even the first doesn't?

Does seem peculiar that such a basic UI function could have slipped by release and not have been flagged immediately if it were ubiquitous in the distribution and not something system specific.

[Jim McIntyre]

Done and case submitted.

[Jim McIntyre]

what if you cut back to just the single

[filename1,pathname1,~] = uigetfile();

I get the same problem:

Operation terminated by user during matlab.ui.internal.dialog.MATLABBlocker/blockMATLAB (line 11)

In matlab.ui.internal.dialog.WebFileChooser/showDialog (line 98)

obj.blockMATLAB();

^^^^^^^^^^^^^^^^^

In uigetputfile_helper (line 50)

ufd.showDialog(dialog_filter, uigetputtype);

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In uigetfile (line 16)

[filename, pathname, filterindex] = uigetputfile_helper(0, varargin{:});

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In junk (line 23)

[filename1,pathname1,~] = uigetfile();

^^^^^^^^^^^

It appears that this is the result of the following change: In MATLAB 2025a and 2026a, MathWorks completed a major core infrastructure migration, transitioning from legacy Java Swing components to a Chromium-based web architecture (uifigure and Chromium Embedded Framework).

My guess is that something left over in my old code is opening a figure, or pointing something somewhere, and then not reseting it, and that's what's blowing up uigetfile.

I've tried a number methods of clearing caches and handles, but so far, nothing has worked.

[dpb]

But if you just restart MATLAB in a new session, does it still error, or only after trying the previous script/function?

[Jim McIntyre]

If I start matlab and run the two-line scipt it runs just fine multiple times. I can then run the other script ONCE. after that either it or the two-line script stalls. Exiting and restarting Matlab resets things.

So, obviously something in the larger script is calling something in the interface that then causes Matlab's newer (non-Java) interface to die.

[dpb]

Gotcha'.....just checking to make sure. MathWorks support will then need the other script as part of the support request to be able to reproduce the issue.

[Jim McIntyre]

While I'm still working with Mathworks tech support on this, I seem to have found a way to make the script work.

Remembering that this is a legacy script that dates back to about 2009, I noticed that it added a path to a directory that contains a bunch of helper functions. Some of these were written by Mathworks and mirror current Matlab internals. For example:

waitbar.m, uistack.m, strsplit.m, strjoin.m, getpref.m, ispref.m, setpref.m, rmpref.m, and there are a few others, too.

I renamed these to the form: legacy_waitbar.m, etc., so that Matlab defaults to the internals, and the script now runs in 2026a.

I have sent the old helper functions to Mathworks support, but haven't received an answer yet as to what was causing the hang.

[dpb]

That it hung is probably owing to the classic UIxxx tools being wrappers around Java Swing components and they end up with a deadlock condition with the internal Java execution thread and Matlab's execution thread.

It still works before R2025a because it was in R2025a that MathWorks removed the support for Java SWING components entirely.

Your fix certainly is the correct solution to move to post R2025a environment; you'll still have the issue if need to keep supporting it on earlier releases.

Answer 1

[Jim McIntyre]

Below is the answer I received from the Matlab development team:

We were able to reproduce the hang by putting the old `strjoin.m` ahead of MATLAB’s current `strjoin` on the path and then calling `uigetfile`. That lines up with your finding that restoring the conflicting helper names brings the hang back, and renaming them to `legacy_*` allows the script to run in R2026a.

At this point, the likely cause is path shadowing: the helper directory added by the script contains an old `strjoin.m` that takes precedence over MATLAB’s current `strjoin`. Newer MATLAB code used by `uigetfile` expects the current implementation, so the old helper function can break the file chooser workflow.

For the immediate workaround, please continue keeping the old `strjoin.m` off the active MATLAB path. For example:

• keep it renamed, such as `legacy_strjoin.m`, if it is not needed by name;
• remove that helper folder from the script’s `addpath` call, if the folder is no longer needed;
• or keep the folder but remove/rename the conflicting MATLAB-function copies, especially `strjoin.m`.

You can check which function MATLAB will call with:

which strjoin -all

In the working state, MATLAB’s installed `strjoin` should appear before any project/helper copy.