Open Bug 85551 Opened 23 years ago Updated 2 years ago

status bar updates happen much later

Categories

(Core :: DOM: Navigation, defect)

x86
Windows NT
defect

Tracking

()

Future

People

(Reporter: gagan, Unassigned)

References

Details

From bug 72805-- it has been noticed that even with the networking library posting the status bar messages, the updates happen much later-- often times giving the appearance of a previous message being stuck for a while (case in point DNS lookup messages) I had believed that there was a bug like this already and so am hoping that bill can just dup this one...
the fix for bug 76722 may make this bug obsolete.
*** Bug 87811 has been marked as a duplicate of this bug. ***
+mozilla 1.0 - we are getting a lot of bugs and complains about this.
Keywords: mozilla1.0
I have noticed this also. OS: NT 4.0 Build: 2001080110 Reproducible: Cannot really say, but 80% ofthe times Step to reproduce: 1. visit webmail.rpi.edu 2. visit bugzilla.mozilla.org 3. visit www.timesofindia.com The status bar doesn't show it is downloading from timesofindia but it shows that data is being downloaded from bugzilla.mozilla.org.
Looks like it was fixed with bug 94038
I'm still having problems with the status bar being slow to update, though only occasionally. Most of the occurances I have seen, 'Resolving' stays in the status bar, 'Connecting' or 'Transferring' never appear. OS: Win98 Build: 2001091303 Reproducable: Again, seems random, about 15% of the time. Possible cause might be multiple hosts being resolved (ie adservers) on a page. Seems to occur during the first load of the page, and reloads after long periods of time.
Setting target milestone to future unless somebody complains.
Target Milestone: --- → Future
*** Bug 104819 has been marked as a duplicate of this bug. ***
Hi there, I think the status bar is very nasty indeed. I get "Document: Done" even if the transfer animation is still active!!!!!!! This is not correct behaviour!!! I'm experiencing this on Linux. I see these problems: 1.) Status bar doesn't tell the right status, for example "querying dns", "sending proxy request", "got response 200, retrieving document", ... (maybe in user friendly language, "Looking up host..." ;-)) 2.) Status bar is influenced by certain actions incorrectly. Maybe if there is a page with frames and one frame is done before another, I suspect that there comes "Document Done" before all other frames are loaded ... there should be a message like "Frame 1/3 Done". The progress bar should be more verbose. I believe the "busy mouse pointer" isn't showing the correct status, too. There shouldn't be any doubts about the status of the browser! So maybe someone cleans up the code a little bit ;).
stephan, WFM? I don't see this.
Assignee: law → nobody
QA Contact: adamlock → docshell
(In reply to comment #10) > stephan, WFM? > > I don't see this. Hi Wayne, nice someone finally takes a look at this ;-). Unfortunately 4 years didn't make it much better. At least I see in Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.5) Gecko/20060810 Firefox/1.5.0.5 that you can trick the browser by doing the following. Scenario 1: 1.) Start loading a web page 2.) Press CTRL-T (new tab) before done 3.) Now the status bar shows the old status from the previous tab until someone writes again to the status bar. This is incorrect and maybe indeed a new error, but it indicates the sloppy status bar handling. 4.) Going back to the previous in the meanwhile finished page won't update the status bar. Solution: Every tab needs its own status bar memory. Switching tabs must switch status bar content. Scenario 2: 1.) Start loading a web page 2.) Press ESC before done 3.) Now the status bar shows "Waiting for ...", but in reality the browser has stopped loading!!! Solution: Every action must update the status bar. You see, it's quite easy to make Firefox show wrong info... the 'state machine' for the status bar is incorrect ... furthermore every tab should have its own status! If you like I can continue like that ;-).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.