131256 - Status line does not reflect actual activity

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Mario]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031114

This applies to most any site that requires the page to be built from many other
sites. The status at the bottom of the browser will simply state "Transferring
from xxx" using the main site url the entire time it is building the page. On
other browsers. ie NS 4.61, that line would change very quickly to show what
url/ip is actually transferring the data. This was critical recently when I had
to debug DSL problems with Pacbell/SBC.

Reproducible: Always
Steps to Reproduce:
1. Go to any page that uses mutiple sites to be built from.
2.
3.

Actual Results:  Status line does not change as sites are contacted.

Expected Results:  Display the actual activity.

Other sites are www.abcnews.com, www.netscape.com. etc.

Comment 1

[[not reading bugmail]]

the problem I see is that it doesn't update if it gets done.. so its missing a
finished call to it or something.. this also happens when going to view pages
where it states: starting plugin: shockwave-<blah> and never changes to get rid
of this.. its like it loads the shockwave content/finishes before telling me it
started..

see www.hardocp.com for an example with shockwave.. and bug 73020 for a longer
shockwave bug that clearly shows status line text updating messed up.

I'll look to see where this started.. I've been seen this for quite awhile now
probably a month now, I hoped it was just a fluke or there was a bug filed, but
this is more than getting irrating the close mozilla1.0 gets. 

also seen in latest nightly W2K, 3-20-03 build.

Marking: NEW.

Comment 2

[[not reading bugmail]]

as of today's build 3-21 it looks like the transfering data -> Document: Done..
works fine.. but plugins are messing with the status line.  

Comment 3

[[not reading bugmail]]

It was working fine in build 12/30 w2k and its broken weird in build 1/4..

Checkins to module SeaMonkeyAll between 12/30/2001 00:00 and 01/04/2002 12:00 :

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=12%2F30%2F01+00%3A00&maxdate=01%2F04%2F02+12%3A00&cvsroot=%2Fcvsroot
Bug 99009: Fix annoying and long standing window status bug.

Bug 116748 : pref doesn't affect anything: scripts and windows - change status
bar text. Or mor
e accurately, the pref affected window.status, but not window.defaultStatus
capabilities. Fixed now to allow/prevent both.

these bugs talk about script & windows, the second is mouseover, which works.. 

and this is related to flash only.. but this bug affects all plugins..

Bug #117398 . flash plugin pauses if you don't move the mouse. Add polling timer
when a flash plugin is active so Xt timers will be processed. Try to improve
interactive performance while there's a lot of flash activity by trying to
interleave the Xt and gtk events more smoothly.

and possibly this: bug 95487 - document.write shouldn't be interrupted, 

which maybe plugin's are affected by the changes to mozilla is stoped running
but the status bar doesn't update.. not getting a stop/status bar update to the
status bar text so it changes to document: done.

Now if this is not really a bug, I can see that the status bar text should say
its running a plugin, and not still starting it.. ie, if you think about video
plugins.. the status always says its starting plugin <blah>/x-<blah>  maybe this
is a wording bug then.. or plugin status needs to have to status line texts..
one for starting, one for running/playing/loading content.

They way it is currently set is that it seems to imply that something about a
page with a plugin doesn't finish loading... which is the irrating part because
the throbber has stopped already.

cc'ing jag... 

jag, when you get a change, can you help out here since you did SR the first two
bugs and maybe able to help give an explanation or clarification if this is
broken/know how to fix, or why its not working the way I think it should.  

Thanks.  Dennis

Comment 4

[Mike Kaply [:mkaply]]

Not Os/2 specific

Comment 5

[Greg K.]

Sending to XP Toolkit/Widgets.

Comment 6

[Samir Gehani]

Nav triage team: nsbeta1+/adt1

Comment 7

[jag (Peter Annema)]

So my first thoughts went to the progress filter we put in c++ (bug 144533 and
bug  168732), but that was a dead end. Some dumps and printfs later it turns out
to be the checkin for bug 171053. I've talked to darin and he said it was okay
to back that out, since we should definitely generate StatusChange notifications
there, and the Progress notifications rpotts was hoping to avoid should have
negligable impact.

Now I suspect this backout will only partially address this bug (since that code
was checked in way after this bug was filed) but it'll at least get the messages
sent a little further down the chain again.

The BrowserStatusFilter only lets progress and state changes through every
400ms, we could probably lower that number without incurring too much of a hit
on pageload times (if at all, gonna test this later). This should help in
getting the status bar more closely reflect actual activity.

Comment 8

[Darin Fisher]

jag: i'm assuming this bug report has morphed since the patch for bug 171053 was
checked in well after this bug was filed.  or is this a meta bug as the summary
sort of suggests?

Comment 9

[jag (Peter Annema)]

See the second and third paragraphs in my previous comment :-)

Yes, this has morphed a little, I guess I could file a bug blocking this one
instead. Should I?

Comment 10

[Darin Fisher]

jag:

heh, yeah... that'll teach me to read more carefully!  anyhow, using this bug
seems fine to me... i just wanted to make sure we weren't missing other factors,
but then if i had read what you wrote i would have seen that you contemplated
that as well... grr :(

i also noticed that switching between tabs does not update the status sometimes.
 like for example if two tabs are busy connecting to a host, switching to a new
tab does not seem to update the status bar to show which host is connecting.  i
know for fact that the socket transport only sends one "i'm connecting" status
message even though it may be connecting for a long time.  are we perhaps not
storing/restoring the last status bar state per tab correctly?  (btw: i noticed
this w/ the 2002113005 trunk build although i think i've seen it with other
builds as well.)

Comment 11

[jag (Peter Annema)]

Yeah, the switching tabs thing is another bug.

Comment 12

[jag (Peter Annema)]

Attachment: Undo checkin from bug 171053

Comment 13

[Darin Fisher]

Comment on attachment 108792 [details] [diff] [review]
Undo checkin from bug 171053

r=darin

Comment 14

[jag (Peter Annema)]

Attachment: Reduce timeout from 400ms to 40ms

This patch will make us update the status bar a little more often so that it
more accurately reflects actual activity. Pageload times go up a little because
of this.

Comment 15

[Darin Fisher]

if this impacts page load performance, then i think we should back off... can
you really tell a big difference visually between say 100ms and 40ms?

Comment 16

[jag (Peter Annema)]

So I tried 100ms (before I posted the patch), and got the same pageload numbers
as with 40ms (both around 1% here). Completely removing the timer made pageload
go up by about 5%.

Comment 17

[jag (Peter Annema)]

This is a pretty fast machine though, so I'm willing to check in the 40ms patch,
and if btek goes up too much, try 100ms and see how much that helps. The updates
in the status bar give more specific visual feedback that the browser is
actually doing work or waiting for something, more so than a spinning throbber.
Anything above 100ms just didn't cut it for me.

Comment 18

[Darin Fisher]

sounds ok i guess... but what about testing this patch out on one of cathleen's
slow machines?

Comment 19

[jag (Peter Annema)]

I'll try that. I'm willing to take a slight pageload hit though if it means
improving the browser's perceived speed.

Comment 20

[Darin Fisher]

Comment on attachment 108800 [details] [diff] [review]
Reduce timeout from 400ms to 40ms

sr=darin (go for it!)

Comment 21

[Asa Dotzler [:asa]]

Comment on attachment 108792 [details] [diff] [review]
Undo checkin from bug 171053

1.3a is complete. not taking further patches.

Comment 22

[Daniel Bratell]

There was a Tp regression of ~3% on luna but it seems to have come half an hour
before this checkin? Bug 110718?

Comment 23

[[e-mail] (gone - use [e-mail] instead)]

Why was this change made?

-                     aLoadFlags | nsIRequest::LOAD_BACKGROUND);
+                     aLoadFlags);

Now, whenever we have a background image, we leave 'Transferring date from...'
on the status bar.

We had a specific bug to fix that...

Comment 24

[Darin Fisher]

stephen: that was required to get status notifications to appear for images at
all.  we need to fix the problem of "transferring from..." sticking on the
status bar a different way ;-)

Comment 25

[[e-mail] (gone - use [e-mail] instead)]

Thanks, that's what I wanted to know.  I looked and didn't see a bug on that, or
am I not looking with the right criteria?

Comment 26

[jag (Peter Annema)]

I just created bug 192059 to deal with the issue raised in comment 23. Marking
this fixed.

Comment 27

[Jo Hermans]

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

Comment 28

[Andreas Kunz]

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

Comment 29

[Paul Wyskoczka]

This seems to be working on the branch.  Marking verified1.4