38554 - Filepicker hangs (or is too slow) on large directories (File->Open File)

Status: VERIFIED DUPLICATE of bug 47795

(Core :: XUL, defect, P3)

Description

[Chris Riddoch]

If a directory contains many (~1000+) files (regardless of type)
Mozilla's "Open file..." dialog box and browser freeze as user
opens the directory to view a list of files to open.

Reproducible every time.

Steps:
1.Create a directory with many files
2.File->Open file...
3.Select large directory

Windows were still movable, but don't redraw on movement.
Mouse and keyboard commands don't register.
Browser unusable.

Browser should have displayed a listing of files contained
in the directory, in the "Open file..." box

Comment 1

[Asa Dotzler [:asa]]

pavlov, is this yours?

Comment 2

[Stuart Parmenter]

the browser doesn't crash for me....   it just takes it about 45 seconds to load
the directory.  if you are really seeing a crash let me know.  I would need need
to do some profiling to see what is going on.. I assume it is general tree
suckage.

Comment 3

[J.R. Greer]

This bug seems to have crept in somewhere before build 2000040315 but after
build 2000031808. Possibly with the change from the native linux file picker
to the mozilla version.
it is 100% repoducable on todays build ( 20000050811 )and all builds
tried including and after 2000040315

in all builds that freeze mozilla become unresponsive and after waiting 1:42
continualy displays this error message on the console untill interupted

	JavaScript error:
	chrome://global/content/filepicker.js line 170:

the test directory contains 1704 files
system is customized Slackware 7 with 128 meg ram

Comment 4

[leger]

Adding crash keyword.

Comment 5

[Asa Dotzler [:asa]]

pavlov, can we assign this to you or someone else in toolkit?  Doesn't seem 
like a Browser General bug to me.

Comment 6

[Andreas Franke (gone)]

The behaviour has changed between the 5/13 and the 5/21 build.
I tested this on PC/Linux with a directory containing 2000 files (0000 - 1999).
- With the 5/13 build, the directory loads "fast" (within less 1 or 2 minutes)
- With the 5/21 build, the directory does not load completely at all. After a
quarter of an hour, I interrupted it with Ctrl-C and took stack traces from
thread 2 and 3.
They both are in __poll. I repeated this with the same build, but this time
I interrupted soon after the file picker switched to a white canvas.
The stack traces are exactly the same. Maybe mozilla is hung?
Unfortunately, my last self-made build is from 5/13, so the stack traces 
probably won't be of much use, but I'm going to attach them anyway.

In one shell (which I did not interrupt) I now see this:

Document http://www.mozilla.org/ loaded successfully
-*- filepicker: CI: {c47de916-1dd1-11b2-8141-82507fa02b21}
-*- filepicker: IID:nsIFilePicker
WEBSHELL+ = 5
JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80520006 [nsILocalFile.isDirectory]"  nsresult: "0x80520006 (<unknown>)" 
location: "JS frame :: chrome://global/content/filepicker.js :: onClick :: line
168"  data: no]

Note that with both builds (5/13 and 5/21) the main window _is_ repainted 
immediately if moved, and the filepicker's "Cancel" button also works fine.

Comment 7

[Andreas Franke (gone)]

Attachment: stack traces of threads 2 and 3, PC/Linux, build 2000052109

Comment 8

[Andreas Franke (gone)]

Removing crash kw, re-summarizing, changing component, reassigning, confirming.

Comment 9

[Andreas Franke (gone)]

The current behaviour has been introduced between 5/13 8:00 and 5/15 20:00.

Comment 10

[Andreas Franke (gone)]

Could this be the cause?

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/components/filepicker/res/content&command=DIFF_FRAMESET&file=filepicker.js&rev1=1.13&rev2=1.14&root=/cvsroot

It's a checkin by [e-mail] on 5/15 00:03:
"Enforce interCaps Mozilla XPIDL style (r=shaver)." 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=mozilla%2Fxpfe%2Fcomponents%2Ffilepicker&file=&filetype=match&who=brendan%25mozilla.org&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F13%2F2000+08%3A00%3A00&maxdate=05%2F15%2F2000+20%3A00%3A00&cvsroot=%2Fcvsroot

Comment 11

[sairuh (rarely reading bugmail)]

ugh, these should go back to me...

Comment 12

[Stuart Parmenter]

I thought bryner already owned this...

Comment 13

[Brian Ryner (not reading)]

dup of 47795, since that one is already plussed.


*** This bug has been marked as a duplicate of 47795 ***

Comment 14

[sairuh (rarely reading bugmail)]

vrfy.