Repository navigation
fix: decode percent-encoded file names when saving downloads - #1426
Merged
Merged
Conversation
getFilenameFromUrl took the last segment of the serialized pathname without decoding it, so a link to "Annual Report.pdf" or "报告.pdf" was saved as "Annual%20Report.pdf" or "%E6%8A%A5%E5%91%8A.pdf". Decode the segment the way browsers do, and keep the encoded form when decoding fails or would produce a separator, a reserved or control character.
Owner
|
@NgoQuocViet2001 Thanks for this, the fallback for unsafe names is exactly the boundary I'd want here. Merged into main, so downloads like |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two kinds of download take their file name from the last URL path segment: links intercepted as downloads that have no
downloadattribute, and the context-menu "Download image" / "Download file" items. That segment comes from the serialized pathname and was never decoded. So a link to/files/Annual Report.pdfsaved asAnnual%20Report.pdf, and/报告.pdfsaved as%E6%8A%A5%E5%91%8A.pdf. Browsers decode this segment, so Chrome or Safari save the same link asAnnual Report.pdf. On the Windows same-origin path, the encoded name also became thedownloadattribute of the transient anchor. WebView2 then used it as is, unless the server sent a Content-Disposition name.This change decodes the segment in
getFilenameFromUrl. The old encoded name is kept in three cases: decoding fails, the result would contain a path separator or a character Windows rejects in file names, or it would contain a control/format character such as U+202E. The data: URI branch is unchanged.npx vitest run tests/unit/event-link-guard.test.js, 55 passed. The new decode,download_fileand native Windows tests fail onmain.npx vitest run, 743 passed and 3 skipped. The 2 symlink cases inlocal-staging.test.tsalso fail onmainhere.prettier --checkon both touched files.