Closed Bug 10335 Opened 25 years ago Closed 25 years ago

[NECKO]Correct time is not displayed when loading url from the command line

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bsharma, Assigned: rpotts)

References

Details

(Whiteboard: [Perf][QA M9 BLOCKER])

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

Steps:
When loading url from the command line a time is displayed on the UI as well as
on the console for the time it took to load about:blank page.
Status: NEW → ASSIGNED
Summary: Correct time is not displayed when loading url from the command line → [NECKO]Correct time is not displayed when loading url from the command line
Target Milestone: M10
I looked in to this problem. Here's my observation..

This problem actually occurs with or without a cmd line url. So, let's assume we
didn't give a cmd line url.

When you load apprunner, this is what you will see,

1) about:blank loads
2) You see a "Document:Done(.11 secs)" message in the status bar
3) You see
   "Document http://www.mozillazine.org loaded successfully"
   "Document Done(.11 secs)"
    on the command prompt
4) mozillazine actually lays out in the content area

So, on the screen it looks like  Document Done(.11secs) was printed for
about:blank and no message gets printed for mozillazine.org (which is what
bsharma has reported)

But actually, the "Document Done(.11 sec)" message is for mozillazine.org (as
you see in the command prompt messages). My theory here is, for some reason,
docloader notifications come earlier than layout can actually render the
document. That's why mozillazine loads after the Document Done  and the document
loaded successfully message for it is printed.

I believe that these are the things that fools the eye in this case ...

a) Since this is the only situation I can think of where we actually load 2
pages( about:blank and mozillazine), but print out status bar messages  for only
mozillazine, (because browserappcore is not initialized when about:blank
loads)it looks like, mozillazine reports about:blanks's loading time.

b) Since we don't have status messages in NECKO, it looks more convincing that
Document Done message was printed for about:blank than mozillazine.  But the
messages in Command prompt are the *true* one.

c) Since the about:blank page is more obvious in NECKO (This page is
intentionally left blank) than in Non-necko where it is quietly loaded, this
forms the prominent fooling agent.

Can someone vouch for me here.  Adding [NECKO] to summary. Cc'ing warren.
Severity: normal → blocker
Target Milestone: M10 → M9
Putting on the blocker list.  We are blocked from giving you Performance data
for Necko without this fix.
As explained in my previous note, this is *not* a bug.  It just *looks* like the
time shown on status bar is for about:blank. But it is *not*. The time shown is
actually for the URL that was provided on the command line. Also,  you don't see
this behavior when you try to load other sites.  I don't see how this affects
performance numbers.

Can someone in the cc list read my note and nod your head, so that I can mark
this invalid.
I've removed the "This page intentionally left blank" joke. Maybe that will
help. I think you probably should mark this fixed or invalid.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Well this page intentionally loads in .11 seconds and otherwise its blank :)
Marking invalid...
Whiteboard: [Perf]
Status: RESOLVED → REOPENED
Reopening the bug since we know now that something is wrong.
Did last night's changes to the image loader help the situation? I thought they
did on my machine, but it was difficult to tell conclusively.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Copying contents from my mail to warren for better tracking ...

I tried today's build. I see little difference. Again both types of
loads go thro' similar code path. Here are the average numbers ...


Site         cmdline load         urlbar laod
aol             .13                1.8
ebay            .2                  .8
etrade          .13                1.4
yahoo           .1                 1.0

When loading from cmdline, the message "Document Done" is printed before
page is actually laid out on the screen.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Moving from Invalid to Reopen.  Thanks warren and radha for working on this for
us!
*** Bug 10342 has been marked as a duplicate of this bug. ***
Radha: Rick Potts said he would help us with this as his next priority. I've
been sidetracked with other necko issues so I haven't had much time to look at
it.
Sure, I have puth this aside too to attend to my other M9 issues.
Blocks: 11349
Assignee: radha → rpotts
Status: REOPENED → NEW
Radha: I'm going to reassign this to Rick since you're not looking at it right
now.
Status: NEW → ASSIGNED
I'm slowly wading through all of the notifications from the load group and
document loader...  There are a number of bugs which are creating this
situation.

I hope to get these notifications sorted out in the AppRunner in the next couple
of days...

-- rick
Whiteboard: [Perf] → [Perf][QA M9 BLOCKER]
*** Bug 11094 has been marked as a duplicate of this bug. ***
Blocks: 11889
adding myself to cc: list.  Paulmac - pls don't mark this verified until the
mail case (crash doing replies) in duplicate bug 11094 gets verified by us.
Thanks.
Blocks: 11094
*** Bug 10333 has been marked as a duplicate of this bug. ***
Also need to verify test case in 11573 which was marked as a dup of 11094, which
is not a crash like in 11094, but garbage in body area of a reply to a POP HTML
msg.
I think that I've fixed up the Document Loader notifications on the M9 branch.
I'll close this bug when I land the changes on the tip...
so, has this actually been check into M9 branch?  if so, when?  or do you need
approval to check in?
The fixes are currently in the M9 branch.

I believe that radha is working on some second order issues related to
framesets.

-- rick
Cool....bshrama..I am working on getting us M9 builds...if they come out before
you leave tonight...check this out...otherwise Monday.

I assume we need radha to finish fix before marking this so, yes?
I'm not sure if radha's stuff needs to be in for this bug or not...  I believe
that frameset notifications were already (kind of) busted in the non-necko
world...

-- rick
I think this can be marked fixed. The frames problem is totally different. I do
see reasonable timing information for urls loaded from cmdline.
bindu can you verify please? thanks
marking fixed
QA Contact: paulmac → bsharma
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
QA Contact: bsharma → esther
This is Verified for the perf tests blockage...all working great.  But esther,
did you want to verify you part too.  Then marked this Verified..thanks!
Status: RESOLVED → VERIFIED
Using 19990820M9 builds on Win98 & mac, 19990816M9 Linux the duplicate bugs
11573 and 11094 are fixed.  This bug is Verified.
Note: (I know the linux build date is before this fix went in but bug 11094
11573 on linux were OK on the 8/16 builds)
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
You need to log in before you can comment on or make changes to this bug.