Closed Bug 39310 Opened 24 years ago Closed 8 years ago

[meta] progressmeter and throbber do not stop spinning

Categories

(Core Graveyard :: Tracking, defect, P5)

Product:
Core Graveyard
Component:
Tracking
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: rekle, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: meta, perf, topperf)

Attachments

(1 file)

testcase; page with animated GIF, browser progressmeter and throbber run forever.
(deleted), text/html
Details 
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
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
*** Bug 39362 has been marked as a duplicate of this bug. ***
*** Bug 39363 has been marked as a duplicate of this bug. ***
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.

<html><body>
<IMG SRC="http://www.nvo.com/motorcycle/nss-folder/scrapbook/Anamationshoei.gif" 
     width=150 BORDER="0">
</body></html>
URL: http://slashdot.org → http://www.nvo.com/motorcycle
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.
Linux build 2000062914. Seems to work OK now.

(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
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]"
Sorry, yes, my mistake. The problem is still there, as described by John.

->ruslan
Assignee: gagan → ruslan
Target Milestone: --- → M18
I've seen this. I think it's imagelib which keeps on issuing asyncreads down to 
networking.
-> imagelib
Assignee: ruslan → pnunn
Actually, imglib should be asking necko for the animated image data.
But the data should be coming from the necko cache, not the server.
-p
Status: NEW → ASSIGNED
Keywords: nsbeta3
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.

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

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.

-p
Target Milestone: M18 → Future
only on this site, minus.
Whiteboard: [nsbeta3-]
This also happens on bugzilla, every time you submit a change to a bug.  Suggest
consideration for rtm on that basis.
Keywords: rtm
*** 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.
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-]
wfm now with Linux build 2000102508.
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).
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
Well then, the title ought to be changed.

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
another url that keeps the throbber spinning:
http://www.britneyspears.com/welcome.html
*** Bug 57551 has been marked as a duplicate of this bug. ***
I can reproduce this bug with the following URL :
http://www.heise.de/newsticker
On this page select on of the links in the middle.
It never stops loading and I see no console finish loading message

*** This bug has been marked as a duplicate of 59494 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
errgkkhh.
resolved wrong damn bug.
-p
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 61531
nav triage team:

Progress meter and throbber stop on heise and britney spears test URL's using
12-28 mac mozilla build. Marking W4M
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
This is not true for build 2000122820 on Win2k.
Throbber keeps running when going to:
http://www.britneyspears.com/welcome.html
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm still seeing the forever-spinning throbber after submitting bugzilla
comments using linux.
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):

http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=UNCONFIRMED&field0-0-0=short_desc&type0-0-0=substring&value0-0-0=ffefew&cmdtype=doit
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
*** Bug 68102 has been marked as a duplicate of this bug. ***
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.
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"


This certainly does make Mozilla look very amatuerish. Would be real good to get 
this one fixed for M0.9.
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
Status: REOPENED → NEW
Keywords: nsbeta3, rtm → mozilla0.9
Whiteboard: [nsbeta3-][rtm-]
Target Milestone: Future → ---
I think I was mistaken in my last comment. The workaround works for some pages,
but not for bugzilla bug lists.

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.
*** Bug 68811 has been marked as a duplicate of this bug. ***
*** Bug 64290 has been marked as a duplicate of this bug. ***
*** Bug 59610 has been marked as a duplicate of this bug. ***
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...
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 :-)

groups.google.com wfm with Linux build 0.8
Keywords: perf, topperf
Come on, this ought to have a milestone...
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).
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
submissions).

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.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
John Morrison,
I think, we need a bug that tracks *all* those bugs. Can't we reopen this bug as
meta-(/tracking-)bug?
Good point. Done. Added to the meta bug for page loading issues bug 71668.
(That probably spammed the universe ...)
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.

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.
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.
Boy, can I be cranky or what. Okay ...

Presenting the meta bug for "throbber spinning forever...".
Blocks: 71668
Status: RESOLVED → REOPENED
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
widening SUMMARY.
Summary: [meta] progressmeter and throbber do not stop spinning after submitting a bugzilla comment → [meta] progressmeter and throbber do not stop spinning
move to tracking.
Assignee: pavlov → jrgm
Status: REOPENED → NEW
Component: XP Apps → Tracking
QA Contact: claudius → chofmann
Summary: [meta] progressmeter and throbber do not stop spinning → progressmeter and throbber do not stop spinning
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
fwiw: www.nvo.com/motorcycle works for me on linux with a fresh cvs pull.
there is a good testcase in 70531:

http://support.microsoft.com/support/kb/articles/Q274/3/08.ASP

takes about 90 seconds to stop spinning the throbber. 3/26/01 macos build.
Severity: normal → major
Summary: progressmeter and throbber do not stop spinning → [meta] progressmeter and throbber do not stop spinning
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.
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.

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.
URL: http://www.nvo.com/motorcycle
Severity: major → normal
Status: NEW → ASSIGNED
Priority: P3 → P5
Target Milestone: --- → Future
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
I don't see a bug that explains why the throbber stops when you scroll.  Does
that play any roll in this?
Keywords: nsCatFood+
Keywords: nsCatFood
all bugs this one depended on are resolved now. What happens now? New bugs to
add or marking this as fixed or something?
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
*** Bug 80845 has been marked as a duplicate of this bug. ***
Depends on: 84471
Both those site wfm with Linux build 2001061308. I don't see any problems.

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

<html><body></body></html
Depends on: 51305, 84774
With Linux 2001062621 I now see the source.

Should bug 91025 be added to the dependancy list ?
Blocks: 104166
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.
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
Status: ASSIGNED → NEW
QA Contact: chofmann → nobody
remove self
Depends on: 156584
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.
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...
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:

<html>
<script>
function close()
{
 alert('Loaded')
}
</script>
<frameset col=* row=* onload="close()">
<frame src="http://sandesh.vsnl.com/en/mail.html?
sid=I/HutbYs9/4&lang=en&cert=false">
</frameset>
</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:
   <html>
   <script>
   window.location="http://sandesh.vsnl.com/en/mail.html?
sid=I/HutbYs9/4&lang=en&cert=false"
   </script>
   </html>
  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.
Depends on: 272274
Depends on: 273595
Depends on: 143398
Blocks: 389325
No longer blocks: 389325
Depends on: 389325
Depends on: 457427
Depends on: 516271
Depends on: 463210
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: