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)
Tracking
()
VERIFIED
FIXED
M9
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.
Updated•25 years ago
|
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
Comment 1•25 years ago
|
||
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.
Putting on the blocker list. We are blocked from giving you Performance data for Necko without this fix.
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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...
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 6•25 years ago
|
||
Reopening the bug since we know now that something is wrong.
Comment 7•25 years ago
|
||
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.
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Comment 8•25 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.
Moving from Invalid to Reopen. Thanks warren and radha for working on this for us!
Comment 10•25 years ago
|
||
*** Bug 10342 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
Sure, I have puth this aside too to attend to my other M9 issues.
Updated•25 years ago
|
Assignee: radha → rpotts
Status: REOPENED → NEW
Comment 13•25 years ago
|
||
Radha: I'm going to reassign this to Rick since you're not looking at it right now.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•25 years ago
|
||
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
Assignee | ||
Comment 15•25 years ago
|
||
*** Bug 11094 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
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.
Assignee | ||
Comment 17•25 years ago
|
||
*** Bug 10333 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
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.
Assignee | ||
Comment 19•25 years ago
|
||
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...
Comment 20•25 years ago
|
||
so, has this actually been check into M9 branch? if so, when? or do you need approval to check in?
Assignee | ||
Comment 21•25 years ago
|
||
The fixes are currently in the M9 branch. I believe that radha is working on some second order issues related to framesets. -- rick
Comment 22•25 years ago
|
||
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?
Assignee | ||
Comment 23•25 years ago
|
||
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
Comment 24•25 years ago
|
||
I think this can be marked fixed. The frames problem is totally different. I do see reasonable timing information for urls loaded from cmdline.
Comment 25•25 years ago
|
||
bindu can you verify please? thanks
Comment 26•25 years ago
|
||
marking fixed
Updated•25 years ago
|
QA Contact: paulmac → bsharma
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 27•25 years ago
|
||
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!
Comment 28•25 years ago
|
||
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)
Comment 29•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•