In testing for another bug I found that calling cancel while we're publising a document doesn't really cancel it, the upload keeps going till it's done or Mozilla gets closed (whichever happens first). There seem to be two problems. One is that in the JS for the dialog we don't have access to the webbrowserpersist object to call cancel on it, the other is that with that fixed (patch coming up) the backend still doesn't cancel any channels open for this (these) upload(s).
Created attachment 120171 [details] [diff] [review] Init gPersistObj so we can call cancelSave on it when cancel is pressed
See bug 201610 for the backend problem.
Created attachment 120175 [details] [diff] [review] Alternate approach, return the persist obj from StartPublishing
Comment on attachment 120175 [details] [diff] [review] Alternate approach, return the persist obj from StartPublishing r=ssu
Attachment #120175 - Flags: review+
Attachment #120171 - Attachment is obsolete: true
Editor triage team: nsbeta1+/adt2 Marking fixed since jag fixed the front-end issue and has filed 201610 for the back-end issue.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Keywords: nsbeta1 → nsbeta1+
Resolution: --- → FIXED
I'm not sure how to verify this one since bug 201610 hasn't been resolved yet.
From my testing with the 2003-05-23-09 Win32 and 2003-05-23-07 Macho trunk builds, I was able to successfully cancel the ftp publishing process in Composer.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.