10333 - [NECKO] All status bar messages are not displayed

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[bsharma]

Build: 1999-07-21-16-M9-NECKO
Platform: Windows 95
Configuration: 133 MHz, 48 MB

Steps:
When loading url's either from command line or from the UI location,
all the status bar messages are not displayed except for the 'Document
Done:' message in the end.

Comment 1

[Radha on family leave (not reading bugmail)]

As per necko team this is a missing feature. cc'ing warren.

Comment 2

[leger]

Putting on the blocker list.  We are blocked from giving you Performance data
for Necko without the fix.

Comment 3

[Radha on family leave (not reading bugmail)]

Don't understand how this affects the performance data.  The performance info is
currently provided by the Document Done(x.xx sec)  message which still works and
works right.  This missing feature doesn't provide the "Connecting to host :..."
messages.

Comment 4

[Warren Harris]

If the problem here is that the performance data doesn't work, then Radha
should own it.

But if the real problem is that status messages aren't displayed, this is
because the http protocol doesn't send them out yet. Gagan should own that.
CC'ing him.

Comment 5

[Gagan]

So which one is it? and I agree with Radha that it should not be a blocker for
performance testing.

Comment 6

[rpotts (gone)]

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

Comment 7

[Radha on family leave (not reading bugmail)]

The real problem for this bug  is, Necko doesn't send out status messages.  So,
re-assigning to gagan.

Comment 8

[leger]

Adding bsharma Steps to Reproduce per her mail......

"Following are the steps that I do and the time that I get for the page load is
not correct:

1. Type apprunner "http://www.yahoo.com"
2. On the Apprunner: First about:blank page gets loaded and the time on the
status bar is 0.44 seconds. (This also displays on the concole). After this
Yahoo site gets loaded but the time on the status bar does not changes and the
time on the console is same 0.44 secs.

For my performance script I read the console messages. Here, the time it is
displaying is for about:blank for all the sites.

Because of this I cannot run the Performance script on Necko build and hence it
is a BLOCKER."

Comment 9

[Gagan]

So there are two micro bugs here... the first one is just that we were
incorrectly displaying the time to load about:blank instead of the actual page.
This should be fixed now and would unblock performance measuring. While life
could go on, I would very strongly recommend using the NSPR logging builtin
Necko for getting the more accurate numbers (pls check with rpotts for more
details).

The second bug is that we are not reporting "Connecting to host..." messages.
This has nothing to do with the performance measuring and is not a blocker.
There is a bigger dependency on how and where these messages originate and the
whole localization issue for which I have opened a separate bug 11708.

So am closing this as fixed.

Comment 10

[Paul Wyskoczka]

Looks like the time is being displayed correctly on the browser and in the dos
box.  However, if we run the apprunner from the commands line it does not
generate the correct time.  In addition, when we run the perl script there is no
output in the dos box and the time that is reported in the browser is incorrect.
I'm not sure if this is a different bug or a part of the same bug.  I will
reopen this bug until that issue is resolved.

Comment 11

[leger]

Clearing FIXED resolution due to reopen of this bug.

Comment 12

[rpotts (gone)]

*** This bug has been marked as a duplicate of 10335 ***

Comment 13

[Jay Patel [:jay]]

verified dup...see Bug 10335

Comment 14

[bsharma]

This bug is not a dup of 10335.
Build: 1999082016M9
Current Behavior: The status bar message displays, "Document Done" when you
start loading url and when the url is loaded completely it displays "Document
Done (*.*** secs).
Expected Behavior: Status bar should display other intermediate messages as
"Contacting, Connecting and Transfering and so on."

Just talked to Radha about this bug and she is saying that this is a missing
feature. So, reopening the bug.

Comment 15

[Warren Harris]

I think Rick should get this one.

Comment 16

[leger]

Clearing Bup resolution.  rpotts, what's the status on a fix for this?

Comment 17

[rpotts (gone)]

This is not really a but it is more of a M10 feature.  Currently, Necko is not
providing status messages out to the containing application.

Since gagan opened bug #11708 for this feature, I'm marking this one a dup...



*** This bug has been marked as a duplicate of 11708 ***

Comment 18

[Warren Harris]

This is not a dup of 11708 as far as I can tell. The http protocol is never
calling OnProgress or OnStatus. This should happen by getting the
nsIProgressEventSink from the nsIEventSinkGetter implemented by the web
shell/doc loader. Reopening.

Comment 19

[leger]

Setting to M10.

Comment 20

[chris hofmann]

rick, any chance of killing this bug in the next few days?

Comment 21

[Gagan]

am getting close... so takin over.

Comment 22

[chris hofmann]

gagan, is this ready yet.  i'd like to get it on the branch.

Comment 23

[Gagan]

Chris: this is really 2 bugs. 1 that messages were not being conveyed from
Necko onto the webshell. And the other is that webshell is not conveying the
same to the status bar. I am talking with Bill Law to figure out if I am doing
something wrong here. Otherwise I will create a new bug and assign it to him and
mark this as depended of that one.

Comment 24

[Gagan]

I have managed to get the notifications for the main page working ok now and I
will be checking those in. However for some reason the notifications for the
inlines are not being conveyed to the status bar. I have filed a separate bug
for that (15395) but this should not be a blocker any more. Am going to check in
the fix now.

Comment 25

[chris hofmann]

gagan's fixes applied to the trunk, not the m10 branch.
looks like there are still two many pieces to this puzzle to
get hooked up for m10.  law, gagan, and a few others need
to huddle so we can get some reliable page loading status
out of the browser.   We can't start measuring and isolating
page loading performace problems until all these pieces get
hooked up and report good data.   This really needs to happen
soon.  lets make sure this is on the top of the porkjockey agenda
for Monday 10/04.  10 4, good buddies?

Comment 26

[chris hofmann]

gagan's fixes applied to the trunk, not the m10 branch.
looks like there are still two many pieces to this puzzle to
get hooked up for m10.  law, gagan, and a few others need
to huddle so we can get some reliable page loading status
out of the browser.   We can't start measuring and isolating
page loading performace problems until all these pieces get
hooked up and report good data.   This really needs to happen
soon.  lets make sure this is on the top of the porkjockey agenda
for Monday 10/04.  10 4, good buddies?

Comment 27

[Brendan Eich [:brendan]]

I'm not sure what can be done for M10, but (while he was in Vegas) I nominated
mscott as big-picture code reviewer and general layer-crossing troubleshooter
here, based on his volunteering previously, and on his doing mailnews progress
(and status?) hookup.  mscott, could you drive this one to conclusion before the
URL dispatching, which must wait a few days for warren's low-level work and for
travis's webshell redesign?

If this is not an M10 issue, chofmann could you change the target milestone?

/be

Comment 28

[leger]

Moving to M11.  Would like fixed ASAP, but not an M10 blocker.

Comment 29

[Scott MacGregor]

I'll let Bug #11708 track the problem of transport messages not getting
displayed. This bug is really about http and ftp not showing status and progress
information. I've posted some comments and open issues about this in the netlib
newsgroup a few minutes ago.

Comment 30

[Gagan]

There is a memory leak problem that I had run into while using the dougt's proxy
stuff. While we discuss whats the best way to resolve it, I am switching to
using PL_events directly and hope to be done with this today. Sorry for the
delay and hang in there...

Comment 31

[Scott MacGregor]

Hey Gagan, can you expand on the memory leak problem with dougt's auto-proxy
code? We use it all over the place in imap and I haven't run into yet. But if
there's a leak I'd like to figure out where. Also, instead of using time to use
PL_Events (which you'd just have to throw away anyway) would it be better to
figure out what's blocking you using the auto proxy code and fix that instead?

Comment 32

[Brendan Eich [:brendan]]

Cc'ing [e-mail].

What exactly is the proxy leak?

/be

Comment 33

[Doug Turner (:dougt)]

during a "fire and forget" async method call, I am only copy the stack address
not their contents.

Comment 34

[Brendan Eich [:brendan]]

Oh.  Then gagan, please stop hacking around with PLEvents and make the other fix
we talked about yesterday: don't pass strings at all, pass integer status codes.
This is the right short and long term thing, no?

/be

Comment 35

[Scott MacGregor]

I actually spent some time with Gagan this afternoon looking at this problem.
it atually doesn't have anything to do with strings. If the proxy is PROXY_SYNC
(which means when you call on the object, you block until the event returns),
managing the strings isn't a problem. We do this all the time in the imap thread
with code like:
        PRUnichar * progressString
        autoProxiedSinkToUIThread->FEAlert(progressString);
        nsCRT::free(progressString);

When we made this change on Gagan's machine, we were running into problems where
the UI thread was getting blocked trying to read data out of an input stream
that represented a file.

Some general debugging needs to be done here because in my mind, I couldn't
really justify how the auto-proxy code (which was originating from a socket
thread and posting an event on the UI thread) could get in the way of the UI
thread reading data from a file thread.

To summarize:
1) If you use the PROXY_SYNC when creating the proxy object, there is no problem
with managing the lifetime of the string. Because your call blocks until the
method on the UI thread returns and then you can free the string
2) If you are using PROXY_ASYNC then maybe we need to look into dougt's string
copying stuff to manage the lifetime of the string.
3) I feel like what Gagan has now should really really work. There is either a
race condition that used to exist but is being exposed now because of these
changes or some other bug that is currently preventing what he has now from
working.

Comment 36

[Scott MacGregor]

If we decide to pass a string ID to the ui thread instead of a string (note but
passing the string isn't what's causing the proxy problems Gagan saw today) we
can't pass the string ID outside of necko. i.e. you'd need a new interface
impelmented by a socket object that would live on the UI thread. the socket
object would get the socket string bundle and could get string ids from the
socket channel (proxied of course), convert it to a string and then pass that
string into the progress event sink associated with the channel.

Note: you can't change the signature of nsIProgressEventsink to take a stringID
instead of a string and expect the webshell (who currently implements
nsIProgressEventsink) to figure out the string because it won't have any idea
what string bundle to use to determine the string.

Comment 37

[Gagan]

brendan: you are right. passing integer codes is the correct solution. However
as mscott pointed out these strings needed to be generated on the UI thread. I
have made some changes last night which seem to be working fine. After verifying
the same I will check this in.

Comment 38

[Warren Harris]

Just returning error codes probably won't work because (as Scott pointed out)
you need to know the right string bundle to look up the error message in.
Consequently, the message lookup should be done by the component producing the
error.

But perhaps this could be made to work if a component could register its set of
error codes and associated string bundle uniquely with a global service such
that any other component could resolve the code to an error string. I'm not
sure the current i18n architecture is up to this.

Comment 39

[Scott MacGregor]

Hey Gagan, how are you doing with the UI proxy class we talked about the other
day?

Comment 40

[Gagan]

mscott: that is what I am using... if I can get past the crash on startup I will
be able to verify that it works. :-(

Comment 41

[Gagan]

Fixed.

Comment 42

[Paul MacQuiddy]

per bsharma and paw, marking verified

Comment 43

[Scott MacGregor]

Hey Gagan...so I was looking around in the code the other day and I noticed that
we're using some hard coded strings for the status bar messages from the socket
service. I think before we can treat this bug as fixed, we need to set up a
string bundle for the necko socket. If you look in mailnews you can see that
each of our protocols has it's own string bundle class. You can probably model
the socket string bundle for the socket service directly off of say the one in
mailnews\imap\src.

I'll send email about this to you, in case we want to represent this work in a
separate bug report.

Comment 44

[Gagan]

We have a separate bug for internationalizing Necko. Thx.

Comment 45

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.