Open
Bug 85551
Opened 23 years ago
Updated 2 years ago
status bar updates happen much later
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
NEW
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...
+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.
Comment 6•23 years ago
|
||
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
Comment 8•23 years ago
|
||
*** Bug 104819 has been marked as a duplicate of this bug. ***
Comment 9•23 years ago
|
||
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 ;).
Comment 10•18 years ago
|
||
stephan, WFM?
I don't see this.
Assignee: law → nobody
QA Contact: adamlock → docshell
Comment 11•18 years ago
|
||
(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 ;-).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•