Closed Bug 197079 Opened 22 years ago Closed 21 years ago

Status bar doesn't display "Stopped" when stop button is clicked

Categories

(SeaMonkey :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: tracy, Assigned: darin.moz)

References

()

Details

(Whiteboard: [adt2])

Attachments

(2 files, 1 obsolete file)

this has been around for quite some time (2002-10-11). See bugscape bug 20546 for original citing in comment 11. That bug was tracking the throbber not stopping in NS. I added this behavior to it, but should have opened a new bug here. Again this isn't critical. Just possibly confusing to those paying attention to the status bar. Stop button does stop the page load. -browse a page that takes some time to load -click the stop button the browser status bar will usually display something regarding connecting too... or transfering data from..., etc. It should display "Stopped". On some occassions, if I click stop just after attempting to load the page, the expected "Stopped" status is displayed. This does, however, seem quite random. My best attempts to reproduce the successful "Stopped" status has been to goto www.netscape.com and immediately click the stop button. cc'ng those in the bugscape bug
This is a fairly high visibility UI feedback regression. Is there some other duplicate bug somewhere covering this (and its dupes)? It seems odd to me that such a visible regression would go uncommented on for so long.
Flags: blocking1.4b+
Keywords: nsbeta1
Asa|Tracy Are you seeing this? I tried a few common sites that i could not reproduce with windows 1.4a.
I have been seeing this since I first reported it in bugscape 20546. It is still present on all platforms. Please read my original comments for how to reproduce this reliably.
I can reproduce this consistently at netscape.com or slashdot or any sufficiently large page. After about 1/4th of the page is loaded I press the stop button and the status bar continues to display "Connecting to cdn.netscape.com..." or "Connecting to images.slashdot.com..."
Regular load of slashdot.org: |Connecting to slashdot.org...|||Stopped |Waiting for slashdot.org...|||Stopped |Transferring data from slashdot.org...|||Stopped |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from images2.slashdot.org...||| |Transferring data from pagead.googlesyndication.com...||| |Transferring data from images.slashdot.org...||| Document http://slashdot.org/ loaded successfully ||||Done Interrupted load of slashdot.org: |Connecting to slashdot.org...|||Done |Connecting to slashdot.org...|||Done |Waiting for slashdot.org...|||Done |Waiting for slashdot.org...|||Done |Transferring data from slashdot.org...|||Done |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from slashdot.org...||| |Transferring data from images2.slashdot.org...||| |Transferring data from pagead.googlesyndication.com...||| |Transferring data from images.slashdot.org...||| Error loading URL http://slashdot.org/ : 804b0002 ||||Stopped |Transferring data from images.slashdot.org...|||Stopped |Connecting to images.slashdot.org...|||Stopped
Those dumps came from this piece of code in nsBrowserStatusHandler.js: updateStatusField : function() { dump(this.overLink + "|" + this.status + "|" + this.jsStatus + "|" + this.jsDefaultStatus + "|" + this.defaultStatus + "\n"); var text = this.overLink || this.status || this.jsStatus || this.jsDefaultStatus || this.defaultStatus;
-> darin who figured out what's going on and knows how to fix it.
Assignee: jaggernaut → darin
patch on the way...
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.4beta
Attached patch v1 patch (obsolete) — Splinter Review
Comment on attachment 122240 [details] [diff] [review] v1 patch patch is real simple. we just suppress status/progress notifications after a channel has been canceled. previously we would only suppress status notification occuring after OnStopRequest, but i think that is wrong. OnDataAvailable is normally suppressed after Cancel, and so should all other necko events other than OnStopRequest. this patch makes it so.
Attachment #122240 - Flags: superreview?(jaggernaut)
Attachment #122240 - Flags: review?(dougt)
Comment on attachment 122240 [details] [diff] [review] v1 patch sr=jag
Attachment #122240 - Flags: superreview?(jaggernaut) → superreview+
Comment on attachment 122240 [details] [diff] [review] v1 patch i am concerned about the the policy change|enforcement wrt onStatus. pleaes add some comments in nsIProgressEventSink stating that these events will not fire before AsyncOpen or after cancel/onStopRequest
Attachment #122240 - Flags: review?(dougt)
Attachment #122240 - Flags: review+
Attachment #122240 - Flags: approval1.4b?
Attached patch v1.1 patchSplinter Review
same thing, but i've fixed up the comments in nsIProgressEventSink.idl ... man that is an old file!! had a lot of broken old comments dating back to '98 ;-)
Attachment #122240 - Attachment is obsolete: true
Comment on attachment 122263 [details] [diff] [review] v1.1 patch a=asa (on behalf of drivers) for checkin to 1.4b
Attachment #122263 - Flags: approval1.4b+
Comment on attachment 122240 [details] [diff] [review] v1 patch clearing a request, this is an obsolete patch
Attachment #122240 - Flags: approval1.4b?
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified fixed with commercial trunk builds: linux 2003-05-02-05-trunk mac 2003-05-02-03-trunk
Status: RESOLVED → VERIFIED
Blocks: 166428
this has returned. seen with recent builds. -click "Stop" button while a large page loads sometimes the status displays stop. but more often it displays some in progress message. sometimes "done" is displayed even though the page still has obviously loading to do.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
adt: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
trace: what recent builds (i am using 1.4rc1) and what url can you repro this on?
Assignee: darin → dougt
Status: REOPENED → NEW
trace, this wfm.
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
use a page that takes a few moments to load. I use home.netscape.com. wait for images to begin to appear, then click the Stop button. Done or some progress message is displayed. Stop will appear if you click Stop at home.netscape.com before anything begins to appear. reopening... this is present on all platforms on trunk and branch builds
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached file simple test case
simple test case that show the problem. unzip. load test.html. hit stop. note the status bar.
During a load of a frameset, if that load is canceled while frames are still being loaded the result of the frameset load -- not the children loads -- will be reported. I can reproduce this problem in 1.3, 1.4a, 1.4b. Tracy tells me he can reproduce this problem in Netscape Communicator 4.8 and in Microsoft Internet Explorer. I am not sure we should fix this for 1.4.
If the fix is trivial, then it should be in 1.4 (there's nothing like having bragging rights over IE). But, if it is a major fix, then 1.5a would be a better target.
pushing out milestone. I am tempted to future.
Target Milestone: mozilla1.4beta → mozilla1.5beta
darin.
Assignee: dougt → darin
Status: REOPENED → NEW
Severity: normal → trivial
Priority: P2 → P5
Target Milestone: mozilla1.5beta → Future
Is this the same as bug 114497?
They are similar bugs. The other bug mentions "aborted" status. This bug has been long fixed though. The status correctly reflects a stopped page load.
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: