Closed Bug 39310 Opened 25 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: