298861 - GTK2 "save page as" dialog is too slow

Status: RESOLVED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Mats Palmgren (inactive)]

GTK2 "save page as" dialog is too slow. I save a lot of pages and I usually
save them into the same directory. In this directory I have ~3200 files.

STEPS TO REPRODUCE
1. load any url
2. invoke "Save Page As"  (CTRL+S)

ACTUAL RESULTS
Nothing happens for about 15 seconds, then the dialog is presented.

EXPECTED RESULTS
Faster respons. The old dialog did not have this performance problem.

PLATFORMS & BUILDS TESTED
Mozilla 2005-06-20-02 trunk Linux gtk2+xft
Firefox 2005-06-17 trunk on Linux

Comment 1

[Ria Klaassen (not reading all bugmail)]

Here on WinXP after clicking "Save Page As..." it takes less than 5 seconds
before the first dialog appears and every next time less than 1 second.
Processor: AMD Athlon XP 2000+. Handy extension: ScrapBook.

Comment 2

[zug_treno]

Maybe related to bug 159107?

Comment 3

[Darin Fisher]

Perhaps this bug should be filed against GTK2?

Comment 4

[richardtallent]

Can confirm issue on Windows XP with directories containing thousands of files.
Population of the file list should not block display and use of the dialog. Also
happens with "Save Image As...".

May be related to hard drive speed, but in any case, use of the dialog should
not require full population of the file list, and code populating the file list
could likely be a bit faster based on response times in other applications.

Windows XP Pro, Athlon XP 2600, 1GB RAM.

Comment 5

[Jan Darmochwal]

The GTK filepicker reads the first 4096 Bytes of each file in the directory before showing the dialog or changing to a different directory (at least it does here). This can take quite some time if there are many files in a directory.

This is probably the same bug as this Gimp bug http://groups.google.com/group/linux.debian.bugs.dist/msg/70fc5c1bfcb0d264

status->new

Comment 6

[Jan Darmochwal]

*** Bug 312654 has been marked as a duplicate of this bug. ***

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

why did you confirm this? is there any proof that this is a mozilla bug instead of a gtk one?

Comment 8

[Jan Darmochwal]

(In reply to comment #7)
> why did you confirm this? is there any proof that this is a mozilla bug instead
> of a gtk one?

Actually, I'm quite sure it's a GTK bug.
If the GTK FileChooser does not recognize a filename extension, it does some mime-type guessing by looking at that file's content, AFAICT. If your home or download folder contain many files with unrecognized/without extensions this can be very slow.
Since Mozilla uses the GTK FileChooser, IMHO the bug becomes a Mozilla bug as well. If this is not the case, just resolve the bug, please.

Maybe component should be "Widget: Gtk" instead of "File Handling".

Filing the bug against GTK2 as proposed in comment 3 is probably more promising than filing it here.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

there's nothing that mozilla can do about gtk bugs. this needs to be fixed in the gtk code. so, this bug should be filed at http://bugzilla.gnome.org (unless, of course, it is already filed there).

Comment 10

[santhosh]

Is there a way, I can get back the old file open/save dialog box. I mean by
writing an extension. I was used to the UI of the old file dialog box. I have
to make more clicks and also wait for a long time in GTK+ file dialog box to save/open a file.