Closed Bug 135771 Opened 22 years ago Closed 22 years ago
filename keeps spinning; should stop instead and have red X
using 4/4 build of netscape 1) launch netscape 2) jump to yahoo.com 3) File | Edit Page 4) make a change/edit 5) Publish 6) leave username and passwd. blank but give it a filename of "yah.html" 7) click on Publish Notice in the progress dialog you get red X's for all the unsuccesful files..this is fine..however, the filename yah.html keeps spinning/publishing. It goes on for several minutes....it should stop immediately and also have a red X next to that filename.
This problem is in either HTTP or nsIWebBrowserPersist code. We don't get the final nsIWebProgressListener::onStateChange message to tell us we should fail. Here's the dubug output for this case: ***** onStateChange request: undefined state flags: STATE_START, * requestSpec=undefined, pubSpec=http://www.yahoo.com/foo.html, aStatus=0 ***** status is 0 ***** onStateChange; NO REQUEST CHANNEL ***** onStateChange request: undefined state flags: STATE_STOP, * requestSpec=undefined, pubSpec=http://www.yahoo.com/foo.html, aStatus=0 Kathy: The fixes we worked on this morning don't help this case.
Assignee: cmanske → brade
Sujay, DSL Michael--do you still see this problem?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
I am still seeing this problem on the 04-09 trunk.
note that this patch has some other fixes (like for bug 135527) The problem isn't in the persist code but in the handling of cancellation. We won't get notification for all files if we cancel. The fix is to set the "busy" state to a non-busy state (failure).
Comment on attachment 78562 [details] [diff] [review] patch r=akkana, but please remove the extra dump() or make it conditional on a debugging variable.
Attachment #78562 - Flags: review+
Comment on attachment 78562 [details] [diff] [review] patch email@example.com
Attachment #78562 - Flags: superreview+
users are very confused by the continuing animation despite the publishing action being canceled; nominate this for adt approval on branch
Whiteboard: publish → publish [adt2]
adt1.0.0+ (on ADT's behalf) approval for checkin into 1.0. Pls check this in to the trunk and 1.0 branch today. Funny thing the patch we see in this bug, seems to include a patch for another bug we just approved ... hmmmmmm.
Comment on attachment 78562 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #78562 - Flags: approval+
This fix was checked into both the trunk and the 1.0 branch Please verify in both locations.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified on both 4/15 trunk and 4/13 branch.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.