[meta] progressmeter and throbber do not stop spinning



Core Graveyard
18 years ago
2 years ago


(Reporter: Richard Ekle, Unassigned)


(Depends on: 2 bugs, {meta, perf, topperf})

meta, perf, topperf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
Go to the above URL.  The page finishes loading (the throbber stops and the
"Document: Done" message appears) but the progress bar at the bottom left on the
status bar continues to animate as if the page is still loading.
over to claudius.
Assignee: don → evaughan
Component: XPApps → Progress Window
QA Contact: sairuh → claudius

Comment 2

18 years ago
Its up to xpapps to start and stop the progress meter correctly.
Assignee: evaughan → don
Component: Progress Window → XPApps
QA Contact: claudius → sairuh
QA Contact: sairuh → claudius

Comment 3

18 years ago
*** Bug 39362 has been marked as a duplicate of this bug. ***

Comment 4

18 years ago
*** Bug 39363 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
For other reported URLs (slashdot.org, www.news.com) I don't see this with 
2000051609. However, I do see it with http://www.nvo.com/motorcycle (which 
I got by randomly following links until one got "stuck").

Despite evaughan's comment, this might not be XPApps -- it may not be getting
a proper notification from necko (possibly on animated GIF). This document, 
loaded from file://, will "spin" forever.

<IMG SRC="http://www.nvo.com/motorcycle/nss-folder/scrapbook/Anamationshoei.gif" 
     width=150 BORDER="0">

Comment 6

18 years ago
Linux build 2000051808. On the motorcycle page, the progress bar now stops on
100% when the page is done loading (as it should do) and 'page loaded' appears.
However the throbber keeps on animating; there is also network activity. After a
couple of minutes I get an alert saying 'The operation timed out contacting
www.nvo.com'. If I click on 'OK', the 100%  bar disappears to be replaced by an
empty status bar. The throbber then stops, but I still see network activity
which never stops.

With the animated gif alone, the gif loads OK and I don't get the 'timed out'
message, but network activity continues forever.

I think there may be two separate problems here, one which causes the 'timeout'
in the motorcycle page, and the other which makes animated gifs download for
ever. I have a feeling the animated gifs problem is a dupe, but I can't find it.

Comment 7

18 years ago
Linux build 2000062914. Seems to work OK now.

Comment 8

18 years ago
Created attachment 10842 [details]
testcase; page with animated GIF, browser progressmeter and throbber run forever.

Comment 9

18 years ago
(Hate to disagree but ...) with 2000062914 win95, linux and mac, the 
progressmeter and throbber still spin forever when loading either 
the URL http://www.nvo.com/motorcycle, or when loading the reduced 
testcase (attached to this bug). 

Sending on to gagan; is the browser code getting the right 
notification from necko? cc: pnunn re: animated gif
Assignee: don → gagan
Summary: "Barber shop" progress bar on bottom status bar get's stuck on. → progressmeter and throbber do not stop spinning, loading this GIF/HTML

Comment 10

18 years ago
Actually, not "forever" ... after about two minutes, an alert is popped up 
on all three platforms:
   "The operation timed out when attempting to contact [a hostname]"

Comment 11

18 years ago
Sorry, yes, my mistake. The problem is still there, as described by John.

Comment 12

18 years ago
Assignee: gagan → ruslan


18 years ago
Target Milestone: --- → M18

Comment 13

18 years ago
I've seen this. I think it's imagelib which keeps on issuing asyncreads down to 

Comment 14

18 years ago
-> imagelib
Assignee: ruslan → pnunn

Comment 15

18 years ago
Actually, imglib should be asking necko for the animated image data.
But the data should be coming from the necko cache, not the server.


18 years ago


18 years ago
Keywords: nsbeta3

Comment 16

18 years ago
Is anybody looking into this ? Surely it must be a major performance hit if we
are requesting animated gifs from the server rather than cache.

Comment 17

18 years ago
pam, sounds like this should be handed off to a necko person, but I do not know to whom to hand it.

Comment 18

18 years ago
We are currently working on both the imgcache and necko cache
which will affect (&probably fix) this bug. No need to keep poking
this bug. We are aware of the problem. I'll keep the bug for now.



18 years ago
Target Milestone: M18 → Future

Comment 19

18 years ago
only on this site, minus.
Whiteboard: [nsbeta3-]

Comment 20

18 years ago
This also happens on bugzilla, every time you submit a change to a bug.  Suggest
consideration for rtm on that basis.
Keywords: rtm

Comment 21

18 years ago
*** Bug 55641 has been marked as a duplicate of this bug. ***
Another possibility is that this is related to bug 54718.  That should be easy
to test by turning on the loadgroup logging as described in that bug.

Comment 23

18 years ago
Is this an NT only problem?  I didn't see any of these pages mess up using 10/26
win98.  I think there is already a separate bug for the bugzilla throbber and
the bug pages don't seem to have images.

I'm putting rtm- in the whiteboard, but you can disagree again if I got it wrong.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]

Comment 24

18 years ago
wfm now with Linux build 2000102508.

Comment 25

18 years ago
This is mostly working now. (Note that the original URL www.nvo.com/motorcycle
has changed design; however, I did get the test case 06/29/00 to get into 
this hung load state on one reload of the page -- so there's still something 
not quite right about dealing with this image).

Comment 26

18 years ago
I still see (on the branch -- is it on the trunk that people are saying WFM?)
the throbber continuing to spin after updating a bugzilla bug, and that bug was
duped to this one.  This is on Linux, so changing platform to ALL.
OS: Windows NT → All
Hardware: PC → All

Comment 27

18 years ago
Well then, the title ought to be changed.

Comment 28

18 years ago
Changing summary: is this better?  (Yes, I'm still seeing it on the limbo builds
of 11/1.)
Summary: progressmeter and throbber do not stop spinning, loading this GIF/HTML → progressmeter and throbber do not stop spinning after submitting a bugzilla comment

Comment 29

17 years ago
another url that keeps the throbber spinning:
*** Bug 57551 has been marked as a duplicate of this bug. ***
I can reproduce this bug with the following URL :
On this page select on of the links in the middle.
It never stops loading and I see no console finish loading message

Comment 32

17 years ago

*** This bug has been marked as a duplicate of 59494 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 33

17 years ago
resolved wrong damn bug.
Resolution: DUPLICATE → ---


17 years ago
Blocks: 61531

Comment 34

17 years ago
nav triage team:

Progress meter and throbber stop on heise and britney spears test URL's using
12-28 mac mozilla build. Marking W4M
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 35

17 years ago
This is not true for build 2000122820 on Win2k.
Throbber keeps running when going to:
Resolution: WORKSFORME → ---

Comment 36

17 years ago
I'm still seeing the forever-spinning throbber after submitting bugzilla
comments using linux.

Comment 37

17 years ago
I have similar to Akkana's "forever spinning" problems when navigating through
various pages, including Bugzilla. From what I see in my Win98 system, problem
is not related to animated gifs, it has something to do with both static and
animated images.
Bug isn't always reproducible, even for the same url. However, the frequency of
it's appearance is annoying. Below there is a Bugzilla url for reproducing the
problem (sorry for the long url):


Comment 38

17 years ago
Nominate for nsbeta1 because it's so irritating to have to click stop on every
third url visited (and never to be sure when the url is actually finished
loading and when it's okay to click stop).
Keywords: nsbeta1

Comment 39

17 years ago
*** Bug 68102 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
I'd like to nominate this for Mozilla 0.9. There are some bugs that make Mozilla
look very amatuerish, and this is definately one of them.

Comment 41

17 years ago
I think this is related to bug 68811. The workaround given in there also seems
to work for this bug.

"if you turn OFF Keep Alive in Preferences > Debug > Networking, then this
problem goes away"

Comment 42

17 years ago
This certainly does make Mozilla look very amatuerish. Would be real good to get 
this one fixed for M0.9.

Comment 43

17 years ago
Excuse me, but after reading this, someone has to wake up: "With the animated
gif alone, the gif loads OK and I don't get the 'timed out' message, but network
activity continues forever.". A simple network analyser would show you the
problem of that trafic!
clearing milestone [to emphasize the beta1 nomination :) ]. also nominating
mozilla0.9 per above comments.

->pavlov since pnunn is on sabbatical. pav, punt as needed, thx!
Assignee: pnunn → pavlov
Keywords: nsbeta3, rtm → mozilla0.9
Whiteboard: [nsbeta3-][rtm-]
Target Milestone: Future → ---

Comment 45

17 years ago
I think I was mistaken in my last comment. The workaround works for some pages,
but not for bugzilla bug lists.

Comment 46

17 years ago
The problem with the Mozilla buglist is a different one, (not sending </html>,
bug 53956), and the keep-alive workaround doesn't work there.

This bug is about a missing content-length header, if I understand it right.
Bug 64290 and bug 68811 are probably both dups of this one.

See also mostfreq bug 38488 which has this keep-alive workaround, too.

Comment 47

17 years ago
*** Bug 68811 has been marked as a duplicate of this bug. ***

Comment 48

17 years ago
*** Bug 64290 has been marked as a duplicate of this bug. ***

Comment 49

17 years ago
*** Bug 59610 has been marked as a duplicate of this bug. ***

Comment 50

17 years ago
If I'm not mistaken this bug, with currently 8 duplicates is a mostfreq.

BTW, this is *only* happening for me in bugzilla, not the attached URL, neither
the testcase or the britneyspears URL.

Stuart, would be very nice if you investigated this...

Comment 51

17 years ago
http://groups.google.com/ is currently loaded but still 'throbbing' too. Stop
button is not greyed. Another page to test against.

Bug not apparent on http://groups.google.com/advanced_group_search so there ya
go :-)

Comment 52

17 years ago
groups.google.com wfm with Linux build 0.8


17 years ago
Keywords: perf, topperf

Comment 53

17 years ago
Come on, this ought to have a milestone...

Comment 54

17 years ago
a new "throbbing" url : http://www.amdzone.com
It used to work until today. it may happen due to their current animated banner
or (less likely) due to changes in build 2001031604).

Comment 55

17 years ago
I'm closing this bug as WONTFIX, since there is no single fix for all the
things noted in this bug. There is more than one way to trigger this
'spinning', some clearly in layout, some in networking, and some as yet
unknown causes, but in any case, they would be better if they were not all
lumped in to one bug based on the symptom only. (For example, pavlov was given
this bug as an imagelib bug, which has nothing to do with bugzilla form

The originally reported URL, slashdot.org has been reported for this bug many
times. It was (perhaps) partially repaired in bug 63750, and I've filed bug
72163 with a simple example for another "mode" of this behaviour. This is a
layout/imglib bug related to the use of percentage width images. This is also
the root cause of http://groups.google.com (mentioned later in this bug
report) not loading.

The follow-on morph (by me) of this bug, was to note a case with an animated
GIF, which was http://www.nvo.com/motorcycle and the attachment to this bug
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=10842. Neither
'hangs' now, although I noticed that we fetch the image in the testcase twice,
due to an unspecified width on the img tag, and this is now bug 72380.

It was later noted that bugzilla form submissions would often hang, although
obviously that has nothing to do with animated GIFs. The bugzilla issue is
also covered by bug 53956 (and it can't be because of a missing </html>
because the parser doesn't care about that). [Also note that bugzilla often
uses multipart/x-mixed-replace, which is a different animal than your typical
HTTP document transfer).

dmose noted that perhaps this was related to bug 54718, but, bug 54718 was
kept as a separate bug with clear steps to reproduce. Go dmose!

It was noted that http://www.britneyspears.com/welcome.html also "spun", but
in current mac/linux/win32 builds it does not. Although, I noted that the
browser UI was noted completely reflecting the 'load is complete' state and
filed bug 72378.

http://www.heise.de/newsticker loads fine in current mac/linux/win32 builds.

bug 64290 (and its duplicate bug 68811) was marked a duplicate of this bug,
but it has a specific, reproducible example related to the use of Keep
Alive. I've reopened that bug.

I'll note that I had previously filed bug 71653: Simple example of 'hanging'
on a HTTP redirect, to cover that specific case.

www.amdzone.com loads fine for me on win32/linux with 0316 builds. But it is 
hopeless on the mac, and should be filed as a separate bug on me, and I will 
narrow that down a bit first. And so I've filed bug 72382.

Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 56

17 years ago
John Morrison,
I think, we need a bug that tracks *all* those bugs. Can't we reopen this bug as

Comment 57

17 years ago
Good point. Done. Added to the meta bug for page loading issues bug 71668.
(That probably spammed the universe ...)

Comment 58

17 years ago
Hmmm, John, I assumed BenB was asking(and my expectation was) that _this_ bug should live on
and be the meta-bug for all of the 'throbber keeps spinning' bugs. That way it'll still show up on
queries and people could comb through the depends list and find the case that matched whatver
they're seeing instead of filing a dupe. In that way this bug would serve as good entry point to the
world of throbber issues.

Comment 59

17 years ago
Okay, perhaps I missed the point. But I doubt that this bug will _stay_
a meta bug for long before someone morphs the meaning again.

Comment 60

17 years ago
I also think it would be convenient to have a bug (perhaps this bug, since it
already has a long cc list and useful comments in it) to track the myriad
problems where the page doesn't finish loading/throbber doesn't stop spinning. 
Bug 71668 (the page loading issues meta bug) is far more general and includes a
lot of issues many of us don't care about.

Comment 61

17 years ago
Boy, can I be cranky or what. Okay ...

Presenting the meta bug for "throbber spinning forever...".
Blocks: 71668
Keywords: meta
Resolution: WONTFIX → ---
Summary: progressmeter and throbber do not stop spinning after submitting a bugzilla comment → [meta] progressmeter and throbber do not stop spinning after submitting a bugzilla comment

Comment 62

17 years ago
widening SUMMARY.
Summary: [meta] progressmeter and throbber do not stop spinning after submitting a bugzilla comment → [meta] progressmeter and throbber do not stop spinning

Comment 63

17 years ago
move to tracking.
Assignee: pavlov → jrgm
Component: XP Apps → Tracking
QA Contact: claudius → chofmann
Summary: [meta] progressmeter and throbber do not stop spinning → progressmeter and throbber do not stop spinning

Comment 64

17 years ago
a meta bug makes no fun without some dependencies.
I looked through the comment by John and collected the bugs I think this one
depends on. Add or delete bugs if you wish!
Depends on: 53956, 64290, 71653, 72378

Comment 65

17 years ago
fwiw: www.nvo.com/motorcycle works for me on linux with a fresh cvs pull.
there is a good testcase in 70531:


takes about 90 seconds to stop spinning the throbber. 3/26/01 macos build.
Severity: normal → major


17 years ago
Summary: progressmeter and throbber do not stop spinning → [meta] progressmeter and throbber do not stop spinning

Comment 67

17 years ago
3/27 windows build, on my PIII 650mhz, 128 ram, took about 64 sec to get
document done, progressmeter completes, but the page is fully loaded within 5 sec.

Comment 68

17 years ago
Using cvs tip build of today on Linux, both the nvo and microsoft urls load fine
and the throbber stops with no noticable delays. The attached testcase also
works fine.

Comment 69

17 years ago
This is a meta bug. It was closed in favour of other more specific bugs, but
was reopened by request. There is nothing to specifically fix or test or 
resolve on this bug.
Severity: major → normal
Priority: P3 → P5
Target Milestone: --- → Future

Comment 70

17 years ago
Thanks for collecting all the bugs about throbber not stopping into this bug! 
Adding nscatfood.  If the problem is solved, we should be able to get all these
bugs verified easily.  Otherwise, what else needs to be done to have the
throbber always "work" from a user's point of view?
Keywords: nsCatFood

Comment 71

17 years ago
I don't see a bug that explains why the throbber stops when you scroll.  Does
that play any roll in this?


17 years ago
Blocks: 71224


17 years ago
Keywords: nsCatFood+


17 years ago
Keywords: nsCatFood

Comment 72

17 years ago
all bugs this one depended on are resolved now. What happens now? New bugs to
add or marking this as fixed or something?

Comment 73

17 years ago
Suggest we keep this open until all the bugs this depends upon are marked
verified, then we mark this fixed.

Should there be regressions, or further bugs found affecting this, we reopen
this one and add the new bug as a dependency (or reopen the dependency that
regressed, obviously).
Depends on: 78371

Comment 74

17 years ago
*** Bug 80845 has been marked as a duplicate of this bug. ***


17 years ago
Depends on: 84471

Comment 76

17 years ago
Both those site wfm with Linux build 2001061308. I don't see any problems.

Comment 77

17 years ago
Well actually, checking again, there is a small problem with
http://groups.yahoo.com/group/OpenCV , if I do 'view source' I see only



17 years ago
Depends on: 51305, 84774

Comment 78

17 years ago
With Linux 2001062621 I now see the source.

Comment 79

17 years ago
Should bug 91025 be added to the dependancy list ?


17 years ago
Blocks: 104166

Comment 80

17 years ago
This bug is still present in Milestone 0.9.5 (Mozilla/5.0 (Windows; U; Win98;
en-US; rv:0.9.5) Gecko/20011011). I just tested using the testcase linked above.

Over 70000 submitted bugs later, and we still ahve not fixed it? What's going on?

Quick notice, the throbber appears that the document is done loading, but the
status bar still says "Transfering document form bugzilla.mozilla.org". Looking
at my firewall status, Mozilla is not still connected to the server, despite
what the status bar states.

Comment 81

17 years ago
And one more time ... (is it really too difficult to read before whining?)

> ----- Additional Comments From John Morrison 2001-03-27 14:41 -------
> This is a meta bug. It was closed in favour of other more specific bugs, 
> but was reopened by request. There is nothing to specifically fix or test 
> or resolve on this bug.
Assignee: jrgm → nobody
QA Contact: chofmann → nobody

Comment 82

16 years ago
remove self


16 years ago
Depends on: 156584

Comment 83

16 years ago
I believe this problem is related to (as I posted in another bug a long time
ago) Mozilla closing sockets before it recieves the complete TCP session. Some
firewalls report recieving ACK packets from webservers (remote port 80) destined
for ports which mozilla had open and subsequently closed before the session was
complete. If this happens then Mozilla might still be awaiting data from a TCP
session but have no way to receive it.

I know for a fact that with Kerio Personal Firewall 2 (free for personal use)
this will be flagged as a "TCP ACK packet attack" in the log file on many
servers particularly on slower connections or where there is a high latency. Its
not reproducable every time but occurs fairly frequently.

The bug report I originally posted was never resolved as far as I am aware.

Comment 84

16 years ago
Oh yes, I forgot to add that this incomplete tcp session behaviour happens
consistantly in relation to the bug in question here. I.E., every time mozilla
"gets stuck" completing a page load, there is consistantly a "TCP ACK packet
attack" in my firewall log file from the target webserver, and *only* under
these circumstances. Which I consider fairly conclusive...

Comment 85

14 years ago
Here is another testcase to reproduce this problem easily in netscape 7/mozilla 
browser on solaris/win2k/linux.
(This problem is appearing even without the animated gifs)
1. Goto this site: http://sandesh.vsnl.com
2. Login with userid: reddy password: reddy
3. Create a new html file in your harddisk like this:

function close()
<frameset col=* row=* onload="close()">
<frame src="http://sandesh.vsnl.com/en/mail.html?

4. Replace the src value of the above html with the new url you got in step 2.
5. Open the html file created in steps 3&4 in netscape/mozilla browser, notice 
that throbber keep looping and it goes for ever. Status bar shows 
that "Transferring data from sandesh.vsnl.com..." for ever.

6. Now, instead of keeping the above url inside the frame do it like this:
  Note that: the window.location value should be replaced with the new URL 
generated in step 2 (after login)
7. Open the html edited in step 6 in netscape/mozilla browser.The problem is 
NOT reproducable.

Note: If we open the above said url inside the frame then throbber goes for 
infinite loop but if we open as said in step 6 this problem will not appear.


13 years ago
Depends on: 272274


13 years ago
Depends on: 273595


11 years ago
Depends on: 143398


10 years ago
Blocks: 389325


10 years ago
No longer blocks: 389325
Depends on: 389325


9 years ago
Depends on: 457427


8 years ago
Depends on: 516271

Comment 86

2 years ago
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.
Last Resolved: 17 years ago2 years ago
Resolution: --- → INCOMPLETE


2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.