Closed Bug 10335 Opened 21 years ago Closed 21 years ago
[NECKO]Correct time is not displayed when loading url from the command line
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.
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: 21 years ago
Resolution: --- → INVALID
Well this page intentionally loads in .11 seconds and otherwise its blank :) Marking invalid...
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: 21 years ago → 21 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!
*** 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.
Radha: I'm going to reassign this to Rick since you're not looking at it right now.
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
*** Bug 11094 has been marked as a duplicate of this bug. ***
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.
*** 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
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
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!
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.