172074 - delay from 1 to several (5-9) seconds from time click "Save" in dialog box until machine ready to do anything else

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Mark E.]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020910

delay from 1 to several (5-9) seconds from time click "Save" in dialog box until
machine ready to do anything else.

have dual 800, 10.2.1, all updates available, tons of disk space.  I am saving
to a seperate partition.

Seen this through 1.0, 1.1, 1.2

Note:  I don't see this with explorer on the same machine, AND THE CRAZY THING,
is I don't see this on my little 600Mhz iBook???? really bizarre

Reproducible: Always

Steps to Reproduce:
1.go to any site
2. try and save any image, to any partition
3. watch spinny wheel

Actual Results:  
spinning wheel

Expected Results:  
saved little pic file nearly instantaneously


Note:  I don't see this with explorer on the same machine, AND THE CRAZY THING,
is I don't see this on my little 600Mhz iBook???? really bizarre

Comment 1

[J. Paul Reed [:preed]]

This is Mozilla bug, not a Bugzilla bug.

->Browser

Comment 2

[Arpad Biro]

Same thing on Mandrake 8.2, Mozilla 1.2.1 (also earlier Mozilla
versions). Mozilla becomes totally irresponsive for nearly 10 seconds,
but the CPU usage remains normal for that period.
Mozilla does this twice during a "save" operation: when starting it
and also when finishing it.

Galeon does not have this annoyance on the very same machine.

Comment 3

[Arpad Biro]

Forgot about the hardware. This is an Athlon machine.

Comment 4

[Martin Macok]

see also bug 133732

Comment 5

[Daniel Wang]

reporter (mark entress), is this a dupe of bug 197765 or bug 159107 ?
(e.g. does deleting downloads.rdf in your profile help?)

Comment 6

[Thomas Lange]

I experienced the same Problem with Win XP. 
Removing the downloads.rdf file (or cutting the entries in an editor) does not
work if the program is still running. 

Since I had too many pages open I would not have liked to close the application
and thus I activated the downloadmanger (I usually only use a progress dialog)
and selected all entries to be removed. However since I never used the download
manager and updated each new version on top of the existing one the file size
was 4MB+ and it took the computer about 15+(!) hours of full workload to remove
all entries, just because there is no single button to remove them at once!
I strongly suggest to add a button to remove all entries and it would be best to
have it available under "Edit/Preferences/*/Downloads" too.

Also since I had choosen to use a progress dialog only it would have been a good
idea to not make any entries at all in that file if the download manager is not
used.
Pretty annoying to get hit by a feature with broken performance that was
explicitly disabled.

Comment 7

[Thomas Lange]

Since I cannot do this I suggest to change "Hardware" and "OS" to "All" in order
to raise the chance of this one being fixed...

Comment 8

[Jonathan Chan]

I am running FireFox 0.9.1 (Gecko/20040626)
P4 2.4C , Win2k SP4 ..

I also experience this, except that it can be a lot longer than 5-9 seconds. It
may take several minutes in some cases. I have seen this in Firefox 0.8 as well.
The browser will become non-responsive and the process in Windows Task Manager
will say "Not Responding" and I get the corresponding 100% CPU load. In my case
since I have HyperThreading enabled, CPU load is 50%. It seems to occur more
often if I have the browser open for a long time. The longer it has been opened,
the longer the delay after clicking "save"

If I close the browser (after it responds again), wait a moment, and restart it,
it will work fine. I don't believe the downloads.rdf file has anything to do
with this. It is almost always clear for me anyway. Right now it is approx 2k.

I use the Download Status Bar extension, although it doesn't seem to affect
this. I have seen it before and after I started using the extension (regular
download progress dialog).

Comment 9

[xolaware.llc]

has anyone looked into whether this is a dupe of other bugs as other comments
suggest?  has anyone looked into whether an owner or appropriate person can
change hardware to all & os to all (though i'm experiencing this on macOS).

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[xolaware.llc]

i am not the reporter, but on the CC: list, because this was failing at one point for me on macOS.  it no longer appears to fail on macOS.

Comment 14

[Wayne Mery (:wsmwk)]

WFM per comment 13