Closed Bug 197289 Opened 21 years ago Closed 20 years ago

Progress meters fail to show progress, remaining blank

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: pbergsagel, Assigned: bryner)

References

Details

(Keywords: regression, Whiteboard: [adt2])

Attachments

(1 file)

fix
618 bytes, patch
shliang
: review+
jag+mozilla
: superreview+
sspitzer
: approval1.4b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030313
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030313

Anywhere Mozilla uses a progress meter the bar fails to change colour to
indicate the percentage of the progress. When a file is downloaded the
percentage numbers and MBs downloaded changes. The process meter is drawn, but
fails to draw the colour bar indicating the percentage of progress graphically.
The progress meter also fails when a new url is loaded. The "M" at the top right
hand corner of the browser will indicate that a page is being loaded.

Reproducible: Always

Steps to Reproduce:
1.Laod a new page into the browser or download a file.

Actual Results:  
The progress meter fails to be drawn. 

Expected Results:  
The colour bar for the progress meter indicating the percent of progress should
be drawn.

I first experienced this in the MacOS X build from March 12 build id 2003031211.
I don't see one on Linux either, in browser window. Downloads behave well.
Similar: bug 193618

*** Bug 197293 has been marked as a duplicate of this bug. ***
all/all - dup is on win98
OS: MacOS X → All
Hardware: Macintosh → All
Keywords: regression
Same problem occurs in windows XP. Dowloads progress meter works fine.
I face same problem on windows XP using Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.3) Gecko/20030312
Blocks: 198119
Marking confirmed per confirmations and dup (and my own confirmation using
FizzillaMach/2003032013).
URL: n.a.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: The progress meter fails (remains blank). → The progress meter fails to draw, remaining blank
No longer blocks: 198119
*** Bug 198119 has been marked as a duplicate of this bug. ***
If this may help. The progress meter at the bottom of the page will draw the
blue stripped indicator just before it should switch to the solid blue progress
bar when opening an email message. I am running Mozilla for MacOS X using the
classic theme.
Flags: blocking1.4a?
Summary: The progress meter fails to draw, remaining blank → Progress meters fail to draw, remaining blank
*** Bug 199699 has been marked as a duplicate of this bug. ***
Summary: Progress meters fail to draw, remaining blank → Progress meters fail to show progress, remaining blank
Flags: blocking1.4a? → blocking1.4a-
Migrating nsbeta1 keyword from bug 199699 (thanks, RKAA). Also, they seemed to
think this was Themes, so reassigning.
Assignee: jaggernaut → shliang
Component: XP Toolkit/Widgets → Themes
Keywords: nsbeta1
QA Contact: jrgm → pmac
I'm not clear on how this could be my form controls checkin if it's a
cross-platform bug.
*** Bug 200386 has been marked as a duplicate of this bug. ***
navtriage: nsbeta1+/adt2
Component: Themes → XP Toolkit/Widgets
Keywords: nsbeta1 → nsbeta1+
QA Contact: pmac → petersen
Whiteboard: [adt2]
This bug started to affect my mozilla 1.3 after I played with several themes. It
affected not only my user account, but also other user account and root account
as well. 

Installing TODAY'S NIGHTLY BUILD 1.4b didn't fix this behavior (I've reverted to
1.3 because Talkback persistently crashed to everytime I clicked on the "send"
button, while it doesn't crash with 1.3):

1. Progress meter of Navigator (browser) almost never works (it only works for a
fraction of a second just before this url http://www.terra.com.br  finishes loading;

2. Removing chrome.rdf file, or all files in chrome subdirectory of all 3 users
(root + 2 regular users) doesn't fix the problem).

3. Progress meter works for everything else (Mail message loading, Downloads,
*.jar mozilla theme downloader/installer, ...).

4. Changing the "colors" at KDE, Gnome or Sawfish didn't affect the bar (I
suspect that the progress meter may be using some kind of "transparent" color,
introduced by my "theme" experimentation).

5. When starting /usr/local/mozilla/mozilla as root, default profile, the
"Preferences" pane is invisible (there is an entry in KDE or Gnome taskbar, but
it is impossible to see the window or its title bar). After switching between
Classic and Modern theme, and restarting mozilla as root, the "Preferences"
windows was an empty window with gray background.

6. Mandrake Linux 9.0 with KDE 3.1.0, Linux Intel plataform
Before you ask me how I could switch themes in item 5 - I deleted root's
.mozilla and created a new profile...
Progress meter (in browser window) is back after installing mozilla 1.2.1
(release). It seems to be version-related (and not profile or customization
related) bug. 
After reinstalling 1.3, progress meter in Navigator (browser) stopped working
again. As I said, differently from the original report, this *only* affects main
browser window. In Download manager, or download dialog window, or in any
actions related to Mail (checking new messages, loading big messages to the mail
pane, checking NG) progress meter works fine in 1.3 too.
Mozilla 1.4b - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030406

Browser windows opened by clicking on links inside e-mail messages often display
a working progress meter, while other links fail.

The following links, when clicked within an e-mail message, trigger the correct
progress meter behavior:
http://www.linuxquestions.org/questions/showthread.php?threadid=52585
http://www.mandrakeclub.com/modules.php?op=modload&name=Splatt_Forum&file=viewtopic&topic=5947&forum=9

The following one, even when clicked from inside an e-mail message, doesn't:
http://registro.ig.com.br/atendimento/

Andreas

Additional testing with Mozilla 1.3 (release):

If I allow pop-up windows for a specific URL, and the URL loading triggers a
pop-up window, then progress meter of the main (bigger) window starts working
exactly at the same time the pop-up window shows up. This might suggest some
kind of interaction between pop-up blocking/controling and browser's progress
meter (e-mail messages don't need a pop-up blocker, nor do download managers...).
Actually there is no need to allow pop-up windows to observe this interaction.
The progress meter resumes working just after the small yellow "blocked pop-up"
icon appears, provided that a significant part of the main page is still not
loaded when it tried to create a pop-up window. (Mozilla 1.3 release)
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401

From comment 18 I clicked on the links provided and did not see the progress bar
with any of them. I have Mozilla set to block pop ups. 
Try sending an e-mail message to yourself including the links, and then click on
them in the Mail window.
Andreas,

I tried sending myself an email with the links and none of the three links
showed the progress bar.
Then probably the bug is more heterogeneous than I thought. In your case all
progress meters don't work, in my case only the one of the Navigator window.
Anyway, I suspect that an independent report would have been marked as
"duplicate" of this bug. Lets wait for the real developers (who probably will
resume working on Monday) to figure this out. I can provide other information or
testing as needed to help them fix this annoyance (before next mozilla release...).
*** Bug 201009 has been marked as a duplicate of this bug. ***
Maybe this is the async loading stuff that went in?
I am using machO build 2003040708 and the progress meters on file download do
not work at all for me.  They remain empty.  The percentages do show up
correctly on the download progress meters.
*** Bug 201887 has been marked as a duplicate of this bug. ***
In PHOENIX 0.5 (release), linux Intel, progress meter worked until an hour ago.
I've just installed 2 new extentions (as root):quickprefs and useragentswitcher,
restarting the browser after each install and drag-n-dropped quickprefs icon to
the toolbar.Now progress meter (for both root and normal user) shows up every
time I load a page, but it is always empty (it doesn't show the progress, unless
some pop-up window/blocking triggers it), disappearing after loading is
complete. Works fine for downloads.I've deleted /usr/local/phoenix directory and
reinstalled the original tar.gz file, but the bug didn't go away.

Can this Linux (browser-only) bug be different from the MacOS bug (affecting not
only main browser window, but all progress meters)? Should I report this bug
separetely, so that it can or not be confirmed for Linux plataform and
investigated separately? Thanks for any advice.
after compiling a list of all the dups/comments, i think the problem that this 
particular bug covers is Mac-only. the one windows dup (comment #4) isn't a 
dup because it was seen in 1.3beta. also, i can't reproduce it on winxp. i 
just started looking at this bug so i will try on Mac tomorrow, i'll look on 
Linux too but i think your bug is probably a separate issue, since you only 
see it in the browser but most of the Mac bugs cover also the downloads dialog.
OK, I reported a separated bug for Linux -bug 202491 - (awaiting for
confirmation), I hope it can be reproducible from the steps I described there
(and here...).
Setting back to Mac/Mac OS X per comment 30.
OS: All → MacOS X
Hardware: All → Macintosh
*** Bug 202670 has been marked as a duplicate of this bug. ***
Attached patch fix — — Splinter Review 
hm, how about if I use the string API correctly...
Attachment #121479 - Flags: superreview?(jaggernaut)
Attachment #121479 - Flags: review?(shliang)
Comment on attachment 121479 [details] [diff] [review]
fix

r=shuehan
Attachment #121479 - Flags: review?(shliang) → review+
Comment on attachment 121479 [details] [diff] [review]
fix

sr=jag
Attachment #121479 - Flags: superreview?(jaggernaut) → superreview+
taking
Assignee: shliang → bryner
Comment on attachment 121479 [details] [diff] [review]
fix

requesting 1.4b approval.  This is a really safe fix.
Attachment #121479 - Flags: approval1.4b?
Comment on attachment 121479 [details] [diff] [review]
fix

a=sspitzer, land away.
Attachment #121479 - Flags: approval1.4b? → approval1.4b+
fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Actually, in 2003052908 OSX I can steal see the progress indicator in status bar
not working.
I concur. It doesn't work in either theme. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It is partially fixed. The progress meters on downloads work fine, but the one
in the status bar at the bottom of the window is still broken.
*** Bug 219974 has been marked as a duplicate of this bug. ***
This bug is about progress meters *anywhere* and was fixed.
Bug 192022 is about the statusbar, where the progress meter still is not shown
(mostly). So I guess this bug can be re-resolved as long as progress bars in
other places work.
marking resolved fixed
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: