Closed
Bug 410566
Opened 18 years ago
Closed 18 years ago
Filter ..apps in file picker when searching for helper applications on OS/2
Categories
(Core Graveyard :: Widget: OS/2, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mozilla, Assigned: mozilla)
Details
(Keywords: fixed1.8.1.12)
Attachments
(1 file)
1.04 KB,
patch
|
mkaply
:
review+
|
Details | Diff | Splinter Review |
When browsing for helper applications the file picker is prefilled with a filter of "..apps" instead of "*.exe;*.cmd;*.com;*.bat", so one has to type in the right filter before actually finding any executables...
This has annoyed me far too long but I always got distracted before searching where it is set. I have definitely seen this problem on 1.8 branch and trunk. Other platforms do something with the special "..apps" filter in their nsFilePicker::AppendFilter, I think we should do that, too. Something simple along the lines of
if (aFilter.EqualsLiteral("..apps"))
mFilters.AppendLiteral("*.exe;*.cmd;*.com;*.bat");
else
mFilters.AppendString(aFilter);
should already do it but I haven't tested it so far.
Hmm, do we want .com and .bat in that list at all?
Assignee | ||
Comment 1•18 years ago
|
||
Urgs, searched myself to death because AppendLiteral didn't compile -- only to find out that our mFilters is an nsStringArray while the Windows version is a simple nsString. So we can use AppendString instead...
I think we should also fix this on the 1.8 branch. We just didn't have this because the OS/2 case was apparently missed in 2002 when checking in the patch for bug 97321.
Comment 2•18 years ago
|
||
Comment on attachment 295213 [details] [diff] [review]
this works
r=mkaply
Attachment #295213 -
Flags: review?(mozilla) → review+
Assignee | ||
Comment 3•18 years ago
|
||
Patch checked into trunk and 1.8 branch.
Updated•11 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•