You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug CefBeforeDownloadCallback callback's Continue method always opens Save As dialog in current user folder if file name is part of path.
To Reproduce
Steps to reproduce the behavior:
When the OnBeforeDownload callback's Continue method is invoked with the exact path e.g. C:\Users\user\Downloads\file.txt and with the argument showDialog as true ,the dialog opens the current user folder, not the required path - user's Downloads folder in this case.
It does not matter which path is used, as far as the file name is part of the path, the current user folder is opened in dialog. If the path is defined without the file name, correct folder is opened in the dialog, but without preferred name and extension.
OnBeforeDownload(CefRefPtr< CefBrowser > browser, CefRefPtr< CefDownloadItem > download_item, const CefString& suggested_name, CefRefPtr< CefBeforeDownloadCallback > callback) OVERRIDE;
callback->Continue("C:\Users\user\Downloads\file.txt", true); // Shows dialog in "C:\Users\user" with suggested file name "file.txt"
callback->Continue("C:\Users\user\Downloads", true); // Shows dialog in "C:\Users\user\Downloads" but with file name field empty.
}
CefSharp wrapper is used to implement the Download handler and respective methods, but the reported issue was marked as upstream issue. See cefsharp/CefSharp#4951 for more details.
Expected behavior callback->Continue("C:\Users\user\Downloads\file.txt", true); will open Save File dialog in the Download folder with file.txt as suggested name.
Screenshots
If applicable, add screenshots to help explain your problem.
Versions (please complete the following information):
OS: Windows 11
CEF Version: 128.4.9, 127.3.5
Additional context
Does the problem reproduce with Google Chrome at the same version?
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
What path shows in dialog if calling callback->Continue("C:\Users\user\Downloads\Downloads\file.txt", true) ?
before testing it make sure C:\Users\user\Downloads\Downloads\ path exists.
This is currently the expected behavior. CEF is intentionally clearing the |default_file_name| value as a Chromium API requirement (code here). Only the Save dialog can currently specify a |default_file_name| value, and in that case it's currently only using the filename (not the path). Chromium is then automatically adding the path value that was last selected in a file dialog (code here).
magreenblatt
changed the title
CefBeforeDownloadCallback callback's Continue method always opens dialog in current user folder
Use the folder passed to CefBeforeDownloadCallback::Continue for file dialog
Nov 13, 2024
Describe the bug
CefBeforeDownloadCallback
callback's Continue method always opens Save As dialog in current user folder if file name is part of path.To Reproduce
Steps to reproduce the behavior:
When the
OnBeforeDownload
callback'sContinue
method is invoked with the exact path e.g.C:\Users\user\Downloads\file.txt
and with the argumentshowDialog
astrue
,the dialog opens the current user folder, not the required path - user's Downloads folder in this case.It does not matter which path is used, as far as the file name is part of the path, the current user folder is opened in dialog. If the path is defined without the file name, correct folder is opened in the dialog, but without preferred name and extension.
CefSharp
wrapper is used to implement the Download handler and respective methods, but the reported issue was marked as upstream issue. See cefsharp/CefSharp#4951 for more details.Expected behavior
callback->Continue("C:\Users\user\Downloads\file.txt", true);
will open Save File dialog in the Download folder withfile.txt
as suggested name.Screenshots
If applicable, add screenshots to help explain your problem.
Versions (please complete the following information):
Additional context
Does the problem reproduce with Google Chrome at the same version?
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: