Closed Bug 192022 Opened 22 years ago Closed 20 years ago

Web page progress bar in statusbar rarely works when browsing, stays blank

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7final

People

(Reporter: savagebiscuits, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: useless-UI, Whiteboard: [patch-ready])

Attachments

(1 file)

v1 patch
2.15 KB, patch
Biesinger
: review+
dbaron
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review 
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
OS: Windows 2000 → 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
URL: http://news.bbc.co.uk/
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
QA Contact: asa
*** 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.
Assignee: blake → general
Component: General → Browser-General
Product: Firebird → Browser
QA Contact: general
Version: unspecified → Trunk
*** 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)
Component: Browser-General → Networking
Assignee: general → darin
QA Contact: general → benc
Summary: Web page progress bar rarely works when browsing. → Web page progress bar in statusbar rarely works when browsing, stays blank
Flags: blocking1.7a?
Keywords: useless-UI
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
Flags: blocking1.7a? → blocking1.7a-
Assignee: darin → cbiesinger
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.
Severity: normal → major
Flags: blocking1.7?
Attached patch v1 patch — — Splinter Review 
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.
Assignee: cbiesinger → darin
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7final
Attachment #144360 - Flags: superreview?(dbaron)
Attachment #144360 - Flags: review?(cbiesinger)
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.
Attachment #144360 - Flags: review?(cbiesinger) → review+
> 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.
Flags: blocking1.7? → blocking1.7+
Attachment #144360 - Flags: superreview?(dbaron) → superreview+
Comment on attachment 144360 [details] [diff] [review]
v1 patch

this would be a good one to get in for 1.7 final.
Attachment #144360 - Flags: approval1.7?
Whiteboard: [patch-ready]
Comment on attachment 144360 [details] [diff] [review]
v1 patch

a=chofmann for 1.7
Attachment #144360 - Flags: approval1.7? → approval1.7+
fixed-on-trunk for 1.7 final
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 241141 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: