User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Using nsIFilePicker with Fx3 on Mac OSX platform. If the appendFilter mask does not properly recognize wildcards. Example: mask = "*.xpi" correctly displays all files ending with ".xpi", but mask = "a*.xpi" still displays the same files but are disabled. It would appear that if the "*" is used, it must be the only character to the left of the period in a "fname.ext" mask. // Works var mask = "*.xpi"; var fp = Components.classes["@mozilla.org/filepicker;1"] .createInstance(Components.interfaces.nsIFilePicker); fp.init(window, "Dialog Title", Components.interfaces.nsIFilePicker.modeOpen); fp.appendFilter(mask, mask); var rv = fp.show(); // Does not work var mask = "a*.xpi"; var fp = Components.classes["@mozilla.org/filepicker;1"] .createInstance(Components.interfaces.nsIFilePicker); fp.init(window, "Dialog Title", Components.interfaces.nsIFilePicker.modeOpen); fp.appendFilter(mask, mask); var rv = fp.show(); Reproducible: Always Actual Results: All choices disabled in filepicker dialog when using "a*.xpi" mask. Expected Results: Enabled choices matching "a*.xpi" mask. The filepicker works as expected in Fx2 builds. Does not work in Fx3 builds.
Component: OS Integration → Widget
Product: Firefox → Core
QA Contact: os.integration → general
Summary: nsiIFilelpicker on Mac not interpreting wildcards correctly → nsIFilelpicker on Mac not interpreting wildcards correctly
Summary: nsIFilelpicker on Mac not interpreting wildcards correctly → nsIFilePicker on Mac not interpreting wildcards correctly
Download this testcase to an otherwise empty directory on your computer, then open it from there (using File : Open File). When you click on either button ("Working File Picker" or "Broken File Picker") you'll be prompted to allow the browser to "request enhanced capabilities" -- you will need to click "Allow" for the testcase to work. I've confirmed that this problem exists in FF3 on OS X (and also in 1.9.0-branch Camino), but not in FF2 on OS X, or in either FF3 or FF2 on Windows and Linux. So I suppose the problem must be somewhere in Cocoa widgets' nsFilePicker.mm.
Assignee: nobody → smichaud
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: smichaud → joshmoz
Status: ASSIGNED → NEW
Component: Widget → Widget: Cocoa
QA Contact: general → cocoa
Priority: -- → P2
See also bug 369756, which I don't think is the same as this.
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.