User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 When browsing, the web page progress bar in the status bar rarely (near 100%) works. It seems to work more often when you go back a page, but even that isn't guaranteed. There is a space created for the progress bar (in themes that have this), even though nothing shows up to fill it. The progress bar worked on the 0.5 milestone build, but since moving onto nightlies on Feb 1st, it's not worked since for me. I can't say if Feb 1st is the first build it happened on, as I haven't used a nightly before that; all I can say is that there is a difference between the 0.5 milestone and the Feb 1st nightly and onwards. Reproducible: Always Steps to Reproduce: 1. Open web page via link, selecting a favourite, or typing a URL. 2. 3. Actual Results: No progress bar seen. Expected Results: Progress bar should indicate how much of the web page has been downloaded. This bug affects the "classic" (Qute) theme, Pinball, Luna (currently using), and Luna Blue.

Can confirm this using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030205 Phoenix/0.5 with fresh profile. OS --> All

Confirmed. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030207 Phoenix/0.5 The BBC page makes a good test URL as it takes long enough to load (owing to the newsticker) that something should be seen in the progress bar during a page load. Status --> New

Also affects the Phoenity Neo theme on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030304 Phoenix/0.5. Does the progress bar work correctly on any theme?

Apparently not with all the themes I've tried. (4-8-03 build; Win 98 SE)

Is this really firebird specific? No pogress bar in Mozilla either.

Also see bug 116693

Confirming that progress bar does not work with every theme I've tried.

Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 When testing on Bugzilla Web Page and Slashdot

confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030828 Firebird/0.6.1+

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

This is not Firebird specific, I am using Mozilla and the problem exists both in 1.4 and 1.5b

Yes, component should be changed. There are several dupes to this one i believe, for example bug 197293, bug 199459 and bug 206158. Also this bug and the one mentioned could be dupe of bug 116693?

yep could be the same bug...

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

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

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

The dupes show this isn't limited to FireBird (confirming with Mozilla 1.6b 20031217). Changing product.

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

This is probably either GUI features or Networking... seen on Firebird also, so I guess it's Necko. (Needless to say I also see it with 1.6 on Win2k)

unlikley we can get this for 1.7 due to work load problems. if some one can pitch in with a good diagnosis and patch please re-nominate

note that this is not necko - nsBrowserStatusFilter gets correct notifications seems to be nsDocLoader, or nsBrowserStatusFilter, or nsBrowserStatusHandler

christian: any update on the investigation of this? i think this is something we'd want to have fixed in 1.7. lot's of sites don't show any progress.

this patch solves the problem. this patch removes the !Equals("text/html") hack and replaces it with a much better solution. we count the number of active requests, and if that exceeds 1, then we enable the mode where we use the percent of completed requests as the progress. this makes for a simple patch. however, it's interesting to note that often times the content-type of the channel is not text/html by the time the OnStateChange notification fires. i believe this has to do with the timing of when AddRequest is called. since it is called from AsyncOpen, there is no way for us to know the content-type for the channel at that point in time. for file channel's it works b/c the content-type is based on the file extension, etc. this just goes to show why the !Equals("text/html") hack was so terrible.

cc'ing jag in case he has time to review the attached patch.

(In reply to comment #22) > christian: any update on the investigation of this? I'm so sorry that I were unable to get to this :( but real life had kept me busy I'll take a look at your patch today

Comment on attachment 144360 [details] [diff] [review] v1 patch ok... looks like this will help.

> I'm so sorry that I were unable to get to this :( but real life had kept me busy no worries christian... especially considering the fact that it looks like i had a hand in causing this regression!

I'd really like to see this repaired for 1.7. Setting the blocking1.7+ flag.

Comment on attachment 144360 [details] [diff] [review] v1 patch this would be a good one to get in for 1.7 final.

Comment on attachment 144360 [details] [diff] [review] v1 patch a=chofmann for 1.7

fixed-on-trunk for 1.7 final

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