fix: support mixed-case extensions in Linux file dialogs #33918
Conversation
shell/browser/ui/file_dialog_gtk.cc
Outdated
| std::string upper_file_extension = base::ToUpperASCII("*." + extension); | ||
| gtk_file_filter_add_pattern(gtk_filter, upper_file_extension.c_str()); | ||
|
|
||
| // if we received a mixed-case extension, add that extension as-is |
There was a problem hiding this comment.
If the filter is set to Foo, it would still not catch files with the extension fOO. Is that expected or should we convert the extension to *.[fF][oO][oO] instead in which case it would catch all such files regardless of the casing?
FYI, my suggestion is put into practice in projects like Firefox in here, and this is how they convert the string.
There was a problem hiding this comment.
That seems reasonable to me. Should I adjust my PR to that effect?
There was a problem hiding this comment.
Sure, unless there are any objections from anyone
There was a problem hiding this comment.
Thanks! I've updated the PR following the aforementioned implementation.
kevinushey
force-pushed
the
bugfix/file-filter-mixed-case-extensions
branch
from
3993f59
to
7366bf0
Compare
|
I think this PR should be ready to go; the associated build failures on AppVeyor appear to be unrelated. Please let me know if there are any other changes I can make to get this over the finish line. |
|
Merging as CI failure unrelated to PR change. |
|
Release Notes Persisted
|
|
I was unable to backport this PR to "17-x-y" cleanly; |
|
I have automatically backported this PR to "19-x-y", please check out #34015 |
|
I have automatically backported this PR to "18-x-y", please check out #34016 |
Description of Change
Closes #33844.
Checklist
npm testpassesRelease Notes
Notes: Fixed an issue where mixed-case extension filters in file dialogs were ignored on Linux.