Windows and UNIX use the string array set by calling the nsIFilePicker interface: AppendFilters() with appropriate values of the filetypes allowed. This allows only certain file types to be opened. Mac shows all file types - it's ignoring the XP list of filters. This is very important for Composer, since we must filter filetypes so users don't try to edit non HTML and Text files.
This blocks the nsbeta2+ bug on the general issue. This is a Mac-specific side issue.
i think dagley was supposed to do the work for this a long long time ago, but I don't know what he did so I'm adding him to the CC list. Steve, can you comment? cc'ing other mac weenies just cuz. I'll take the bug for now, i guess. M21 until we get approval.
Assignee: trudelle → pinkerton
Component: XP Miscellany → XP Toolkit/Widgets
OS: Windows NT → Mac System 9.0
Target Milestone: --- → M21
Putting on [nsbeta2-] radar. Not critical to beta2.
nsbeta3-, new functionality, too late to be adding significant risk.
Whiteboard: [nsbeta2-] → [nsbeta2-],nsbeta3-
Target Milestone: M21 → Future
This is pretty easy to do, and not risky. We suffer greater risk by having it now work, like you are allowed to open inappropriate file types in editor (hey, let me try and edit the Mozilla binary!).
This bug blocks 43834, which, despite not working on Mac, has been marked fixed (thanks charley). It's really not that hard, and a significant usability penalty for mac users. Please reconsider.
nsbeta2-, not holding PR2 for this.
need info: I thought this work had stayed assigned for so long (more than a year) because it was *not* so easy to do, and was considered risky too. Has that changed? Do we now know how to do this quickly with little/no risk?
Whiteboard: [nsbeta2-] → [nsbeta2-] [need info]
Somone needs to spend 10 mins looking at Nav services docs to find out how to do this. Nav services has good file filtering hooks, so filtering on file extension, or using IC to map file extension to type, then filtering on type, would not be that hard.
i think when dagley looked at it for 10 minutes, he concluded it would be difficult given what the navservices in 8.5/8.6 provides...if we could require OS9, it would be better, but....
Nav services prior to 2.0, which is only available built into Mac OS 9, does not allow complete customization of the types popup (you always get some extra junk added by Nav Services pre-2.0). Apple's suggestion was to require Mac OS 9 if we wanted only our items on the menu. The obvious answer is to use the StandardFile style custom DITL workaround but I didn't want to go there due to localization issues (um, I18N, could you please give use some DITL loving to go along with all those localized string bundles? Thank you and I'm sorry our OS is lame :-(
I don't think requiring 9 is an otpion. Simon, where does this fall on your prioritized list of Mac problems? Pink will investigate what is available in pre-9 App Services, but we think this is lower priority than many other bugs we have.
Target Milestone: Future → M18
I don't think it's bad that nav services adds a couple of menu items to teh popup in the nav services dialog. In fact, in the simplest case, can't we just keep this popup hidden, but still have a file filter? I think is a medium priority mac issue; adding nsmac2.
ok, i think we can do this w/out any of the hassle previously thought. IC is back in the build, and we don't need any UI to have a plain-jane filter. i think we should nsbeta3+ this.
Whiteboard: [nsbeta2-] [need info] → [nsbeta2-]
i have this working w/out the type popup so you only get all the filters applied at once. I'll check in the code when i get back. note that the "allFiles" filter is ignored.
Whiteboard: [nsbeta2-] → [nsbeta2-] fix in hand
Well Okay! nsbeta3+, p4 for M18
Priority: P3 → P4
Whiteboard: [nsbeta2-] fix in hand → [nsbeta2-] [nsbeta3+] fix in hand
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.