Closed Bug 298861 Opened 16 years ago Closed 16 years ago

GTK2 "save page as" dialog is too slow

Categories

(Core Graveyard :: File Handling, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: mats, Unassigned)

References

Details

(Keywords: perf, regression)

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
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.
Maybe related to bug 159107?
Perhaps this bug should be filed against GTK2?
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 312654 has been marked as a duplicate of this bug. ***
why did you confirm this? is there any proof that this is a mozilla bug instead of a gtk one?
(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.
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).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.