Open Bug 463210 Opened 12 years ago Updated 2 years ago

"Loading" indicator in browser doesn't stop spinning, although all the requests to web pages/css/scripts/images on a page are finished


(Core :: General, defect)

Windows XP
Not set




(Reporter: zerkella, Unassigned)



User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9) Gecko/2008052906 Firefox/3.0

In my AJAX-application I request some data, Firefox 'loading' wheel indicator goes on, and at the bottom of a page Firefox shows progress-indicator for loading this request. But under some circumstances even after the request is fully complete the wheel never stops spinning and progress-indicator is not removed. 

I tried FF, 3.0 and latest 3.1b.pre, all under Windows XP SP2 - they all show same buggy behaviour.

The problem doesn't affect functionality of application. It just annoys user and makes bad look of the application.

Reproducible: Sometimes

Steps to Reproduce:
The bug is not well reproduced, because it happens from time to time. 

The main algorithm is:
1) I create hidden IFRAME to emulate history back/forward switches. I put it in the body of document. When user switches different modes of AJAX-appication I make iframe.src = '/blank.html#INT_INT', where INT_INT is just string holding two integers (for example: 1_212827).
2) After some time user presses the link on a page and application requests new data from server via creating SCRIPT element and putting it in HEAD-section of document. The wheel starts spinning.
3) Server returns data with 200 OK response. No other requests are going at that moment. 
Actual Results:  
The wheel continues spinning and progress-indicator is not removed. In FF 2.0 it shows that loading is complete (100% of indicator is filled), in FF 3.0 it shows 0%.

Expected Results:  
The wheel must stop and become grayed. The progress indicator must be removed from bottom of a page.

I tried to investigate the cause of the problem, but couldn't get the reason. The things that can help to remove that bug are:
1) It never occurs in IE/Opera/Safari/Chrome

2) It somehow connected to iframe presence in my applications. Without iframe it never occurs.

3) The bug is not directly connected to iframe. Because the data request and processing of its results do not use iframe in any way. Also the bug occurs any time my data request is made - the can be already loaded in iframe an hour ago. Or it can be loading currently.

4) To stop the wheel-indicator I can: set new iframe.src or request some images from server. After these actions the wheel stops and progress indicator is removed.

5) Sometimes the bug can occur without the data request - I just move my mouse over some element with hover style with image background. The background for this element starts loading from server and after it is loaded I see the same bug - wheel is spinning, the progress-indicator is not removed.

6) I tried to reduce the problem to some small testcase, but couldn't - it didn't occur in smaller apps. It doesn't always occur even in my testcase, although I make same actions and browser makes same requests. So I came to conclusion, that there's something wrong with Firefox timeings or its css-iframe-img-request processing system.
Version: unspecified → Trunk
Version: Trunk → 3.0 Branch
Need a testcase or this bug will go nowhere
(In reply to comment #1)
> Need a testcase or this bug will go nowhere

Ok, here it is:
login: ff_test
pass: ff_test

Easy variant:
1) Load
2) Move mouse to date switching panel (currently it says "5 November 2008") over any of date controls. Hover method from CSS will work and background image '' will be loaded from server by Firefox (that is not Javascript, just css rule). Wheel will start spinning in Firefox and won't stop when image loading is finished. Works in FF3 (trunk version too), but not always. Try some refreshes.

More complicated variant, works more often (95%)
1) Load
2) Click on date switching panel on month name (currenty it's "November"). The month view will load.
3) Click on any date name (e.g. "5 - today") - that will return you to day view mode.
4) Click arrows near current date on date switching panel - left or right, it doesn't matter. Try some clicks. For every new day you see application makes request to server to show you events for this date. Usually the bug will come the first click you make - wheel will start spinning in Firefox and won't stop when data request loading is finished.
I can confirm this with Seamonkey trunk but could be still a server issue.
Will try to generate a http log tomorrow but I don't know if this is enough information for the developer.
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
Version: 3.0 Branch → Trunk
(In reply to comment #3)

Ok, waiting for it.

I used Firebug to check status of net requests - they all were completed, but loading indicator still was there. 

I think that something is wrong in internal counter of opened connections in Firefox or whatever method browser uses to check whether loading status should be shown.

I managed to fix it in the following way:
// Data request arrived
OrgDay.prototype.onPlansArrived = function() {
  // Process data

  // Fix firefox bug
  if (b.ff)
    setTimeout(function () {var img = new Image(); img.src = '';}, 1);

So after each data request I ask FF to make one more request to get image from server. First time FF really loads image, and every next time it is quickly fetched from cache. This solves problem with no additional overhead for app - loading wheel disappears. This method also points that the problem is somewhere in browser engine - after image is loaded opened connections are rechecked, none found and so FF restores normal status of indicator.

Of course this method eliminates bug only in this particular case. It's impossible to know and call such a func every time some css-background-image/script/iframe/flash or any other resource is loaded.
This is a bug in nsBrowserStatusFilter.cpp.  Here's what I see in nsBrowserStatusFilter::OnStateChange when clicking on the day link:

nsBrowserStatusFilter::OnStateChange (this=0xc48f0c0, aWebProgress=0xc31d934, aRequest=0xd56e4c0, aStateFlags=65537, aStatus=0)
  - This is an nsOnloadBlocker being posted for the toplevel content window
    (from XBL binding processing)
nsBrowserStatusFilter::OnStateChange (this=0xc48f0c0, aWebProgress=0xc31d934, aRequest=0xd56e4c0, aStateFlags=65537, aStatus=0)
  - This is the start of a load in the subframe of the toplevel content
    window.  We have STATE_IS_NETWORK set, so we go ahead and reset our
    mTotalRequests/mFinishedRequests, then set mTotalRequests to 1.
nsBrowserStatusFilter::OnStateChange (this=0xc48f0c0, aWebProgress=0xc31d934, aRequest=0xd56e4c0, aStateFlags=65552, aStatus=0)
  - This is the onload blocker being removed.  We increment mFinishedRequests
    to 1.

After this, we lose, because mFinishedRequests is 1 too big.  So when all the loads for the subframe finish we'll be at mTotalRequests == 4 and mFinishedRequests == 5.  After that we'll notify our listener on request starts but NOT request ends (which is backward from the broken-looking thing where we apparently try to notify stops but not starts right now).  In any case, that's why the throbber is going: it gets a start but not a stop.  It's not an issue for the initial subframe load, because the STATE_IS_NETWORK end will trigger the call.  But then next time we add/remove a request to the loadgroup (e.g. the arrow click in the steps to reproduce) we get a never-ending throbber.

It looks like this has been a problem ever since the status filter landed...

jag, you want to take a look at this?  Where should this bug live?  It's certainly not a docshell bug...
Ever confirmed: true
Component: Document Navigation → General
QA Contact: docshell → general
Jason, you might be interested in giving this a stab...

I wasn't able to reproduce using current nightly
Flags: needinfo?(zerkella)
(In reply to Boris Zbarsky (:bz) from comment #6)
> Jason, you might be interested in giving this a stab...

bz, anyone else to tag?   (if this still exists)
Severity: normal → minor
Flags: needinfo?(bzbarsky)
I wouldn't be surprised if this still exists, and I have no idea whom to tag; no one seems to care about the browser status filter in practice.
Flags: needinfo?(bzbarsky)
Flags: needinfo?(zerkella)
You need to log in before you can comment on or make changes to this bug.