172001 - nsIFilePicker.files returns returnCancel in mode modeOpenMultiple

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Ashish Bhatt]

nsIFilePicker.files returns "returnCancel" in mode modeOpenMultiple if more than
9 files are selected. It returns "returnOk" for 9 files or less.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this the Windows filepicker implementation? Or all implementations?

Comment 2

[Ashish Bhatt]

On Windows only. On linux and mac filepicker does not let you select multiple files.

Comment 3

[Ashish Bhatt]

Attachment: test case for modeOpenMultiple

Comment 4

[Ashish Bhatt]

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.

Comment 5

[David Ascher]

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

Comment 6

[(not reading, please use [e-mail] instead)]

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

Comment 7

[(not reading, please use [e-mail] instead)]

Attachment: patch

Comment 8

[(not reading, please use [e-mail] instead)]

asa, worth taking for 1.4.1?

Comment 9

[(not reading, please use [e-mail] instead)]

fixed.

mscott checked in my fix for me.

r=pavlov, a=sspitzer (for 1.5 final)

Comment 10

[Malcolm Rowe]

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

[[e-mail]]

Attachment: Win9x patch?

Previous patch only fixes WinNT/2K/XP; this might fix it for 9x/ME as well.

Comment 12

[(not reading, please use [e-mail] instead)]

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

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

thanks neil.

Comment 13

[(not reading, please use [e-mail] instead)]

> 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

[Asa Dotzler [:asa]]

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

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 15

[(not reading, please use [e-mail] instead)]

Comment on attachment 130803 [details] [diff] [review]
patch

we'll want this patch for 1.4.1, too.

Comment 16

[(not reading, please use [e-mail] instead)]

fixing it the right way is now bug #218242

Comment 17

[(not reading, please use [e-mail] instead)]

mscott checked in neils fix for win9x for 1.5 final

Comment 18

[Mike Kaply [:mkaply]]

Both patches checked in to 1.4.1