Go to the above url. If it doesn't happen, reload. A fraction of a second after "Done" is displayed in the status bar, it changes to "Sending request to www.yle.fi..." and stays that way even though the throbbe has stopped and the page is loaded.

I do not get "Sending request...". After 2 reloads I got "Transferring data from..." remaining in the status bar.

Me too. Apparently something has changed in Moz or the behavior depends on what the page contains (it changes constantly because it's the news page of the Finnish Broadcasting Company).

i'm frequently seeing both "Transferring data from.." and "Sending request to .." after page finished loading. i'm heavy tabs user, and "Sending request to ..." appears to be tab issue - for example, when i'm typing this in bugzilla tab, status bar shows "Sending request to nnm.ru...", and nnm.ru is actually already loaded in another (first) tab.

Can we get a release version or build number? cc: neeti for ideas on how to analyze this.

windows build 2002091904 here. here are some steps which in most cases trigger this bug. 1. open several tabs with some content 2. open new tab 3. type mozillazine.org into location bar, press enter and _quickly_ switch to another tab 4. wait while mozillazine tab loads completely 4. now status bar in all tabs displays "Sending request to mozillazine.org.."

darin: is this docshell?

sounds like tabbed browser may be the culprit. cc'ing jag.

Could this be the filter failing to cancel the timer?

ooh.. maybe.. yeah! i bet that is the case.. can someone verify if this bug still exists with the latest nightly builds. thx!

I was actually thinking about something slightly different. If I recall correctly we cancel the timer when we detect the network/stop state. That should be sufficient, right? What about when a user manually interrupts the download (e.g. hits the stop button) or when we time out?

there should still be a STATE STOP event in that case.

I see this behavior (except with "Transferring data from") with 2002092408. This is really annoying - please fix :).

.

I haven't seen the problem anymore. The problem decribed in comment #5 is still present, although it seems to be another issue.

It seems that all bug 166428, bug 185547, bug 190044 and bug 190442 are caused by the same problem, which is neither Mail/News or browser component. Could anybody with better insight confirm this suspection and file a new general bug?

I see this again in 1.3beta Linux i386 MailNews when pressing the GetMessage button on an account in succession. After that, sometimes it is correct ('Done'), sometimes it's 'Sending request...' and sometimes 'Transferring data from ...'. I still cannot see the rule, it seems to be random. Concurring threads problem ?

Ah, there is one rule: When the spinning bar right in the status bar appears and spins, the status afterwards is correct. But the spinning bar does not appear always, and in that case the status bar messages stays wrong.

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

i can still reproduce this bug in linux trunk build 20030506. seems like the patch for bug 197079 didn't do the trick.

ok, looking at the source for http://www.yle.fi/yle24/navi/vasen.html it seems like it is loading http://www.yle.fi/yle24/navi/kuvat/oranssilaatikko.gif during MouseOver and during the body's onLoad in order to prefetch the image. so, probably that image load is not being assigned to a loadgroup or it is not having the LOAD_BACKGROUND flag set.

Well, I have a patch, though this particular site could be exposing another bug (namely that we have all these notifications after the document is done loading). To understand the fix, here's the problem: Say a site loads an image from JS after the document is done loading (e.g. on mouseover). This load triggers status updates, which will be put on a timer to throttle status bar updates. When the image is done loading (STATE_IS_STOP && STATE_IS_REQUEST && mFinishedRequests == mTotalRequests && !isLoadingDocument) we call nsBrowserStatusHandler's onStateChange which will set the status to "Done". We don't cancel the timer however, so the timer can fire with an old "Transferring ..." after we set status to "Done".

Comment on attachment 122836 [details] [diff] [review] Also cancel timer for last request after document is done loading sr=jst

Comment on attachment 122836 [details] [diff] [review] Also cancel timer for last request after document is done loading r=darin

Comment on attachment 122836 [details] [diff] [review] Also cancel timer for last request after document is done loading a=sspitzer, since asa already has this blocking 1.4 final.

Checked in.

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

is this networking? dougt sent it to browser-general.