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

RESOLVED FIXED in Future

Status

SeaMonkey
General
P5
trivial
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: tracy, Assigned: Darin Fisher)

Tracking

Bug Flags:
blocking1.4b +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2], URL)

Attachments

(2 attachments, 1 obsolete attachment)

14.41 KB, patch
Details | Diff | Splinter Review
86.06 KB, application/octet-stream
Details
(Reporter)

Description

15 years ago
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

Comment 1

15 years ago
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

Comment 2

15 years ago
Asa|Tracy

Are you seeing this?  I tried a few common sites that i could not reproduce 
with windows 1.4a.
(Reporter)

Comment 3

15 years ago
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.

Comment 4

15 years ago
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..."

Comment 5

15 years ago
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

Comment 6

15 years ago
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;

Comment 7

15 years ago
-> darin who figured out what's going on and knows how to fix it.
Assignee: jaggernaut → darin
(Assignee)

Comment 8

15 years ago
patch on the way...
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.4beta
(Assignee)

Comment 9

15 years ago
Created attachment 122240 [details] [diff] [review]
v1 patch
(Assignee)

Comment 10

15 years ago
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 11

15 years ago
Comment on attachment 122240 [details] [diff] [review]
v1 patch

sr=jag
Attachment #122240 - Flags: superreview?(jaggernaut) → superreview+

Comment 12

15 years ago
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?
(Assignee)

Comment 13

15 years ago
Created attachment 122263 [details] [diff] [review]
v1.1 patch

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 14

15 years ago
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?
(Assignee)

Comment 16

15 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

15 years ago
verified fixed with commercial trunk builds:

linux 2003-05-02-05-trunk
mac 2003-05-02-03-trunk
Status: RESOLVED → VERIFIED
(Assignee)

Updated

15 years ago
Blocks: 166428
(Reporter)

Comment 18

15 years ago
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 → ---

Comment 19

15 years ago
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]

Comment 20

15 years ago
trace: what recent builds (i am using 1.4rc1) and what url can you repro this on?
Assignee: darin → dougt
Status: REOPENED → NEW

Comment 21

15 years ago
trace, this wfm. 
Status: NEW → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 22

15 years ago
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 → ---

Comment 23

15 years ago
Created attachment 124863 [details]
simple test case

simple test case that show the problem. 

unzip.
load test.html.
hit stop.
note the status bar.

Comment 24

15 years ago
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.  

Comment 25

15 years ago
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.

Comment 26

15 years ago
pushing out milestone.  I am tempted to future.
Target Milestone: mozilla1.4beta → mozilla1.5beta

Comment 27

15 years ago
darin.
Assignee: dougt → darin
Status: REOPENED → NEW
(Assignee)

Updated

14 years ago
Severity: normal → trivial
Priority: P2 → P5
Target Milestone: mozilla1.5beta → Future

Comment 28

14 years ago
Is this the same as bug 114497?
(Reporter)

Comment 29

14 years ago
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
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.