Closed Bug 202491 Opened 21 years ago Closed 19 years ago

Progress meter in browser no longer works after installing new themes

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: afunkebr, Assigned: jag+mozilla)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

I've seen this bug in both mozilla 1.3 and later, and in phoenix 0.5 and later.
In both browsers the progress meter no longer works after the steps described
below, unless a pop-up window appears or is blocked early in the page loading.
The progress meter still works fine when the browser window is opened by
clicking on a link within an e-mail message and for downloads, and this aspect
makes this bug not a duplicate of bug 197289
(http://bugzilla.mozilla.org/show_bug.cgi?id=197289).

Reproducible: Always

Steps to Reproduce:
Mozilla 1.3 and later:
1.Install ORBIT theme
2.Restart browser


Phoenix 0.5 and later
1. Install new theme (e.g., Crystal) and restart browser
2. Install 2 new extensions: quickprefs and useragentswitcher
3. Customize toolbar and drag quickprefs icon, dropping it to the toolbar
4. Restart browser


Actual Results:  
Progress meter no longer works for the current user.

Expected Results:  
Progress meter should continue working as usual.

If the theme installation or the extension installation was done by root, for
all users of the machine. The bug does not disappear by a fresh install of
mozilla or phoenix to /usr/local, nor by deleting or renaming any of the users
profiles. 
Upgrading to the latest nightly (as of 2003-04-06) doesn't fix the problem.
Downgrading to mozilla 1.2 fixes the problem (progress meter works again).
Tested with today's nightly (2003_04_17_05), still no progress bar in browser
(only an empty field, no color showing progress).

Andreas
related to bug 190967?
Mozilla FireBird 0.6 (Glendale)

Progress meter works in the new window opened by choosing File -> New Window
(with the default "Project page" as Home Page). "New window" won't work after
setting "Home Page" for any of 5 other URLs I tried, including the "Release
Notes" page.
Using the Pinball theme the progress bar on the download manager and on the
status bar of the main browser window work for me. 

RH9. Trunk (1.4b+) cvs+xft2+svg.

about: buildconfig
Configure arguments
--enable-svg --enable-calendar --enable-crypto --enable-default-toolkit=gtk2
--disable-toolkit-gtk --disable-toolkit-qt --enable-xft --enable-freetype2
--enable-cpp-rtti --enable-cpp-exceptions --enable-extensions --with-system-jpeg
--with-system-zlib --with-system-png --with-system-mng

At one stage my progress bar wasnt working  (bug 193618), but seemed to
work again when the patch for bug 174471 went in. 


I'll try ORBIT ...
Following up on comment 4. I've just tried orbit3+1 and orbit retro (is there
just plain orbit?) from mozdev.org. Progress bars (and throbber) work for me in
both mail/news window and main browser window. I like the look of orbit3+1 too,
it may trump pinball for me.

I've only really closely examined the throbber and progress bars with looking
into this bug. 

Can someone confirm for me expected behaviour (asks he after saying it works for
him!):

o The throbber is active whenever the browser is establishing or has established
a connection. 

o Solid expanding progress bars occur when a download is in progress and the
browser knows the size of the download. 

o Barber poles are shown when a download is in progress but the browser does
_not_ know the size of the download. 

Some questions

I'm wondering about the extent to which the look of the progress bar is
themeable - could a theme replace it with a barber pole animated gif intentionally?

If the barber pole appears because the size of a download is unknown (above) is
 the size unknown because the web server does not report it (because the server
does not know it, dynamically generated, ...)?

In the orbit1+3 theme the visual behaviour of the circular throbber ring seems
to indicate more than a simple repeating pattern. Is it showing each http
connection for part/fragments of a page? Do all the throbbers do likewise?


Just add that the test page I'm using is the png specification  linked from
http://www.w3.org/Graphics/PNG/. Its just over 200 kB.


In bug 197289 comment 15 Andreas reports

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;

I believe I see the same behaviour.

It seems the progress meter is only briefly displayed because the page
is composed of lots of small images and several document.write scripts
but overall is not that large download.  The user experience is that
the page seems like it is taking a long time to download because it
does take a while to finish downloading and rendering all the
components (say 2 s in my environment). The progress bar is only
active briefly (hmm, 1/4--1/2 s at a guess).  

Running iptraf at the same time the page is being downloaded and
composed seems to show a number connections being opened and closed. I
should know this but does each image result in a separate request and
connection? Maybe the issue is more about compound pages than 
about new themes?


I've just tried downloading into a tab
http://www.w3.org/TR/2003/WD-DOM-Level-3-Core-20030226/DOM3-Core.html
which took approx 10s and iptraf showed open connection and data being downloaded.

The progress bar didnt show up until the end, and then only flickered briefly
showing 100% full and then was cleared.

On http://www.terra.com.br I see the progress bar showing partial completion of
compound page download at seemingly piecewise times.

This is using modern.

Now I dont know whether this was the behaviour before I installed and used the
themes. I thought before the themes and with the themes that I was seeing the
progress bar showing correctly indicating download. But now I cant be certain
because whilst I saw the progress bar and it generally looked ok, or so I
thought, it cant be sure it was correct. Pay more attention to detail.

I'll have to try and remove the themes and their residuals and try again. I did
that once before and seemingly they, or their residuals, can be sticky.
I've moved my original .mozilla out of the way and started anew. Themes should
be completely gone. 

Sometimes I get a progress bar in the browser, sometimes I dont.  

For example, I got a progress bar on
http://www.renderx.com/Tests/doc/html/tutorial.html

On http://www.terra.com.br no progress bar first time,
then I turned pop-ups off and shift-reloaded and got a fleeting progress bar. So
then I tried cycling pop-up on/off followed by multiple shift-reloads. First
shift-reload after changing pop-ups setting, no progress bar. Second and
subsequent shift-reloads (fleeting) progress bar each time.

On the w3c specs generally I'm not getting a progress bar, or only getting a
fleeting completed progress bar at the end, for example no progress bar for
http://www.w3.org/TR/xslt20/

So overall, sometimes I'm getting the progress bar and sometimes I'm not. 

I believe by moving .mozilla out of the way (.mozilla.O) and starting afresh I
have banished all theme traces - except for classic and modern which live
elsewhere (I'm using classic which is the default). So that would mean it isnt
themes causing the problem and that this is a dup?

With all traces of themes removed I still get a sometimes works/sometimes doesnt
browser progress bar. So I'm wondering if this is a duplicate or dependency of
193618. 


bug 192022 seems to be the root bug for mostly not working progress bar on all
systems. Duplicate of it?
After installing Mandrake 9.2, and getting the nightly build below, progress
meter worked fine, until I tried to switch themes. In Preferences theme switch
didn't work (from modern to classical), and when using the apply theme option in
the View menu, progress meter stopped working after I restarted mozilla. I
noticed the following error messages in a recently created ~/.xsession-errors :

Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined
Entity 'ns_graphs' not defined

This is what Help -> About -> Mozilla shows:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216
Never mind.

The ns_graph error messages have nothing to do with mozilla, but rather are
generated by xfce4 desktop manager...   ;^)
Spent about 2 hours trying to find out what file(s) have been changed by the
theme switcher, and no hope.

Removed ~/.mozilla  (for both regular user and root), renamed and reinstalled
/usr/local/mozilla, tried renaming user's and global chrome.rdf, localstore.rdf,
xpti.dat, appreg) and no luck in getting the progress bar to display a different
color for the progress of the page loading (the actual applet seems to be
loaded, and the progress bar "template" shows up, but no color change is
visible, unless a pop-up window is blocked). Changed themes many times, and
still the same problem.

I give up, this is just a "cosmetic" bug anyway...
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.