Closed Bug 272087 Opened 20 years ago Closed 18 years ago

filepicker.files enumerator does not correctly getNext() file

Categories

(Core :: Widget, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: tim_clancy, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When using a @mozilla.org/filepicker;1 object and using the nsIFilePicker
interface to initialize the dialog with the flag modeOpenMultiple in XUL/JavaScript.

The filepicker.files property (nsIFilePicker.files) is a nsISimpleEnumeration
interface.  The files property does not correctly get the next file in the
enumeration when using a control loop to test filepicker.files.hasMoreElements()
and then filepicker.files.getNext()

Reproducible: Always
Steps to Reproduce:
1. Create a JavaScript function that will initialize a filepicker dialog with
the modeOpenMultiple flag as follows:
function openFiles() {
  var nsIFilePicker = Components.interfaces.nsIFilePicker;
  var fp =
Components.classes["@mozilla.org/filepicker;1"].createInstance(nsIFilePicker);
  fp.init(window, "Select Files", nsIFilePicker.modeOpenMultiple);
  var res = fp.show();
  if(res == nsIFilePicker.returnOK) {
    var loopcount = 0;
    while(fp.files.hasMoreElements()) {
      if(i > 3) {
        break;
      }
      f = fp.files.getNext();
      f.QueryInterface(Components.interfaces.nsILocalFile);
      alert(f.leafName);
      loopcount++;
    }
  }
}
2. Create a XUL file that on some action will call this function
3. Install the XUL file so that it can be accessed via a chrome URL, and the
JavaScript file is included in the XUL file via a chrome URL.
4. Run the XUL file, open the filepicker, and select 3 separate files.
Actual Results:  
I receive 3 alert boxes with the name of the first selected file.  The function
then breaks because of the loopcount check to prevent infinite loops.  Without
this check, function loops forever.  hasMoreElements() never returns false, and
getNext() returns the same file.

Expected Results:  
The software should have alerted me with three seperate names of three seperate
files.  hasMoreElements() should eventually return false, and getNext() should
return the next element in the enumeration.

I've tried posting this around the web to see if there is a bug in my code, as
well as rewriting my code numerous times, numerous ways - no help.  The function
provided is abridged/edited to demonstrate the problem and the exact files can
be provided if necessary.
I tested this bug a bit here's the results:

OS              Firefox Version  Result
Gentoo          1.0.5            No Prob  
Fedora          1.0.4            Bug Confirmed
Fedora          1.0.5            No Prob
Fedora          1.0.6            No Prob
Windows XP Prof 1.0.4            Bug Confirmed
Windows XP Home 1.0.4            Bug Confirmed
Windows XP Home 1.0.6            Bug Confirmed

Sorry, Scrub one of those tests, never happened.

Fedora          1.0.6            No Prob

--> becomes -->

Fedora          1.0.6            Not Tested
Assignee: bross2 → nobody
I just encountered this problem in a XULRunner application. I'm using version 1.9a3pre_2007032508 on Windows XP. I always get the same file and hasMoreElements() always returns true.
Assignee: nobody → general
Component: General → Widget
Product: Firefox → Core
QA Contact: general
In a rather strange coincidence, this came up on m.d.t.xpcom earlier today. See http://groups.google.com/group/mozilla.dev.tech.xpcom/browse_thread/thread/43b9c054e52265ca/3793551bf2b36ab6  . The two replies haven't appeared in Google groups yet, but the gist of it is, each time you access fp.files, you get a new enumerator. You need to store fp.files in a local variable and read check hasMoreElements() from it.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.