If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

nsIFilePicker.files returns returnCancel in mode modeOpenMultiple

RESOLVED FIXED

Status

()

Core
Embedding: APIs
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: Ashish Bhatt, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({fixed1.4.1})

Trunk
x86
Windows NT
fixed1.4.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.4.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [for 1.4.1, we want both patches])

Attachments

(3 attachments)

1.34 KB, text/html
Details
1.93 KB, patch
Stuart Parmenter
: review+
(not reading, please use seth@sspitzer.org instead)
: approval1.4.1+
(not reading, please use seth@sspitzer.org instead)
: approval1.5+
Details | Diff | Splinter Review
2.59 KB, patch
(not reading, please use seth@sspitzer.org instead)
: review+
(not reading, please use seth@sspitzer.org instead)
: superreview+
(not reading, please use seth@sspitzer.org instead)
: approval1.5+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
nsIFilePicker.files returns "returnCancel" in mode modeOpenMultiple if more than
9 files are selected. It returns "returnOk" for 9 files or less.
Is this the Windows filepicker implementation? Or all implementations?
Summary: nsIFilePicker.files returns returnCancel in mode modeOpenMultiple → nsIFilePicker.files returns returnCancel in mode modeOpenMultiple
(Reporter)

Comment 2

15 years ago
On Windows only. On linux and mac filepicker does not let you select multiple files.
(Reporter)

Comment 3

15 years ago
Created attachment 101336 [details]
test case for modeOpenMultiple
(Reporter)

Comment 4

15 years ago
Note: Save the attachment locally and then run the test case, Otherwise it will
fail because it requires enabled privillages if the file is not local.

Updated

15 years ago
QA Contact: depstein → ashishbhatt

Comment 5

14 years ago
FYI: we find this in Komodo as well, alas.

I looked into this, and I think the 10 limit isn't issue.

we pass in a buffer (right now, of size MAX_PATH) to GetOpenFileNameW(), at
least on winnt and up (we have our own implementation, named GetOpenFileNameA()
on win 9x)

so in nsFilePicker::ShowW, we allocate a buffer and use it in a OPENFILENAMEW
structure.

when we fail (in this way), GetOpenFileNameW() fails silently.

but if I bump up the buffer, it works, or at least, it takes more to fail.

MAX_PATH is the current size, and that works well for one file.

but multiple files are all on the same buffer, in the format:

dirpath\0\file1\0file2\0...filen\0\0

working on bumping up the buffer to a more reasonable value
Assignee: pavlov → sspitzer
Created attachment 130803 [details] [diff] [review]
patch
asa, worth taking for 1.4.1?
Status: NEW → ASSIGNED
Flags: blocking1.4.x?

Updated

14 years ago
Attachment #130803 - Flags: review+
fixed.

mscott checked in my fix for me.

r=pavlov, a=sspitzer (for 1.5 final)
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 10

14 years ago
In case anyone ever wanted to fix this 'properly', MSKB article 131462 
describes how a hook procedure can be used to reallocate the buffer on demand.

HOWTO: Handle FNERR_BUFFERTOOSMALL in Windows
http://support.microsoft.com/?kbid=131462

Comment 11

14 years ago
Created attachment 130815 [details] [diff] [review]
Win9x patch?

Previous patch only fixes WinNT/2K/XP; this might fix it for 9x/ME as well.
Comment on attachment 130815 [details] [diff] [review]
Win9x patch?

r/sr/a=sspitzer for the win9x side.

thanks neil.
Attachment #130815 - Flags: superreview+
Attachment #130815 - Flags: review+
Attachment #130815 - Flags: approval1.5+
> In case anyone ever wanted to fix this 'properly', MSKB article 131462 
> describes how a hook procedure can be used to reallocate the buffer on demand.
>
> HOWTO: Handle FNERR_BUFFERTOOSMALL in Windows
> http://support.microsoft.com/?kbid=131462

thanks for the info.  

stuart was hoping there was something like this, but I couldn't find it.

let's spin up a new bug about this, for 1.6

Comment 14

14 years ago
Comment on attachment 130815 [details] [diff] [review]
Win9x patch?

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #130815 - Flags: approval1.4.x+
Comment on attachment 130803 [details] [diff] [review]
patch

we'll want this patch for 1.4.1, too.
Attachment #130803 - Flags: approval1.5+
Attachment #130803 - Flags: approval1.4.x+
fixing it the right way is now bug #218242
Blocks: 218242
mscott checked in neils fix for win9x for 1.5 final

Whiteboard: [for 1.4.1, we want both patches]

Comment 18

14 years ago
Both patches checked in to 1.4.1
Flags: blocking1.4.1? → blocking1.4.1+
Keywords: fixed1.4.1

Updated

14 years ago
Blocks: 224532
You need to log in before you can comment on or make changes to this bug.