While working on flatpak-ing a Qt application I noticed a misbehavior when using xdg-desktop-portal with the xdg-desktop-portal-gtk. The application is using QFileDialog in save file mode and while specifying the filters it also set a default suffix via setDefaultSuffix(). The application code is something like:

QFileDialog dialog(this);
QStringList filters;

filters << "DLT Files (*.dlt)" <<"All files (*.*)";
dialog.setDefaultSuffix("dlt");
dialog.setWindowTitle("Export to DLT file");
dialog.setAcceptMode(QFileDialog::AcceptSave);
dialog.setDirectory(workingDirectory.getExportDirectory());
dialog.setNameFilters(filters);
dialog.exec();

The misbehavior happens when the user choose a filename without explicitly specify an extension: when xdg-desktop-portal-gtk is in use the file is not saved outside the sandbox. I used dbus-monitor and fired some use-cases in order to understand what was happening. This table summarize what I saw:

While it may be nicer from a user point-of-view that xdg-desktop-portal-gtk portal returns a path with an extension, I don't think that this is the main issue. What is happening here is Qt not respecting the portal decision and changing the path in application-space behind its back. I looked at Qt source code and I think that I've found the main issue here:

    if (!usingWidgets())
        return addDefaultSuffixToUrls(selectedFiles_sys());

When !usingWidget() is true it means that we are using a native dialog and we should not modify the URLs in this case. I tried to blame from where this code comes from in order to understand better the reasoning behind it and it comes from the Qt4 days here, introduced by this commit.