In SWT save FileDialog on Mac, displayed filename not actual filename.

[andrewthomas28]

In the SWT save FileDialog on Mac, if the user changes the filter, the extension in the displayed filename does not change. But the actual filename reported by the dialog (and used for the overwrite check) differs - it is consistent with the chosen filter.

I'm observing this with Eclipse 4.39 rich-client platform on my Mac OS 26.3.1 (a). Don't know what other versions it affects.

For example, if the displayed filename is myfile.foo, and you change the filter to *.bar, the displayed filename remains at myfile.foo, but the actual filename reported by the dialog is myfile.bar.

May be similar to behavior of [Big Sur] File dialog does not change file name when switching file type.

Below is example code to demonstrate the issue.

package mypackage;

import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.FileDialog;
import org.eclipse.swt.widgets.Shell;

/** Test the standard SWT file dialog.
 * @author thomasa
 */
public class TestFileDialog {

	public static void main(String[] args) {
		final Display display = new Display ();
		Shell shell = new Shell(display);
		shell.setLayout (new FillLayout());

		Button btn = new Button( shell, SWT.PUSH );
		btn.setText("Show File Dialog");
		btn.addSelectionListener( new SelectionAdapter() {
			@Override
			public void widgetSelected(SelectionEvent e) {
				FileDialog dlg = new FileDialog( shell, SWT.SAVE );
			
				dlg.setFilterNames("foo", "bar", "baz");
				dlg.setFilterExtensions("*.foo", "*.bar", "*.baz");
				
				dlg.setFileName("myfile.foo");
				
				String file = dlg.open();
				if ( null != file ) {
					MessageDialog.openInformation( shell, "Chosen Filename", file );
				}
			}
		});
		
		shell.open ();
		
		while (!shell.isDisposed ()) {
			if (!display.readAndDispatch ()) display.sleep ();
		}
		display.dispose ();
	}
}

[Phillipus]

I don't think changing the filter extension has ever updated the displayed file name's extension on Mac. Not that I can ever recall.

[elsazac]

I explored a little bit around the filename with the selected file extension using setNameFieldStringValue:

String x = this.fileName.substring(0, this.fileName.lastIndexOf('.') + 1) + this.selectedExtension;
setFileName(x);
panel.setNameFieldStringValue(NSString.stringWith(x));

However, this doesn’t stay in sync with the selected filter. The name field continues to show the old extension, and the updated extension only appears correctly on the next invocation of the dialog. it seem like something with NSSavePanel the update only takes effect when the dialog is reinitialised.

Is this like a known limitation of the FileDialog, or is there any Cocoa delegate/API that could be used to react to filter changes and keep the filename in sync?

@Phillipus Any suggestions?

[Phillipus]

@Phillipus Any suggestions?

No, sorry. I asked an AI agent, this is its reply:

• NSSavePanel (the native macOS save dialog that SWT wraps) has its own logic for how it handles the name field (nameFieldStringValue) when you also set allowed file types (via allowedFileTypes or setFilterExtensions in SWT).

• The panel often prioritizes or overrides the default filename based on the selected filter/extension. This can cause the displayed name in the text field to differ from what you passed in, even though the final returned URL might still be correct (or close).

• Apple made security/sandbox-related changes starting around Catalina (10.15) and tightened them further in Big Sur and later. One documented side effect is that external apps (including SWT) have reduced ability to freely change the filename dynamically while the panel is open, especially when filters are involved. Apple explicitly told Eclipse developers in one related bug that you can't reliably call setNameFieldStringValue in certain scenarios anymore because the dialog now runs in a separate sandboxed process.

[elsazac]

I think this is what mentioned in the commit. The sync is not possible still. It avoids using setNameFieldStringValue and instead use setAllowedFileTypes.

when I tested also, when I attempt to update the filename field it doesn't persist due to the value getting overridden by the dialog and only shows up correctly on the next invocation. This is due to the sandboxed NSSavePanel on macOS 10.15+ versions.