Closed
Bug 238391
Opened 20 years ago
Closed 12 years ago
quit-application-requested should support cancelling
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: timeless, Assigned: timeless)
References
Details
Attachments
(1 file, 2 obsolete files)
1.65 KB,
patch
|
Biesinger
:
review-
|
Details | Diff | Splinter Review |
Attachment #144582 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 2•20 years ago
|
||
Um... of course, written like this, it also supports uncancelling :-P
the alternative would be to have a callback object where you could do: actor->Cancel(refuser) so that the thing trying to quit could be told which thing refused. but for the time being i'd like to do this.
Comment 4•20 years ago
|
||
FWIW this way is more compatible with FF too ;-)
Comment 5•20 years ago
|
||
Hmm... I think (not tried) you could break this as follows: 1. Observer 1, written in any language, sets cancelQuit to true. 2. Observer 2, written in JS, throws an exception. 3. When Observe returns the exception gets propagated out (for some reason). 4. The quit is not cancelled at Observer 1's request :-(
Attachment #144582 -
Flags: review?(neil.parkwaycc.co.uk)
Attachment #144582 -
Attachment description: honor toolkit api → steal toolkit impl
Attachment #144582 -
Attachment is obsolete: true
Attachment #144750 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 7•20 years ago
|
||
Comment on attachment 144750 [details] [diff] [review] honor toolkit api Surely this solves the wrong problem - to honour the (unwritten?) contract you enumerate the observers and abort the loop as soon as one cancels.
Attachment #144750 -
Flags: review?(neil.parkwaycc.co.uk) → review-
Comment 8•20 years ago
|
||
Can we expect this bug to be solved before 1.8 final? This would be very useful considering bug 28385.
Flags: blocking1.8a?
Attachment #144750 -
Attachment is obsolete: true
Attachment #146193 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Comment 10•20 years ago
|
||
LpSolit@netscape.net: if you're volunteering to fix this bug, then take ownership and set flags. otherwise please leave it alone.
Status: NEW → ASSIGNED
Flags: blocking1.8a?
Comment 11•20 years ago
|
||
Comment on attachment 146193 [details] [diff] [review] bail at first rejection >+ var observer; >+ while (observers.hasMoreElements() && >+ (observer = observers.getNext())) I'm not sure that quitting the loop if the getNext returns null is useful. >+ catch (ex) I would have thought having the catch inside the loop would be more reliable.
Comment 12•20 years ago
|
||
Comment on attachment 146193 [details] [diff] [review] bail at first rejection Nits: 1) I don't think that a null getNext() should exit the loop, getNext should throw on a serious error 2) I think that you should treat an exception in the notification as a failure to cancel the quit rather than as a force quit.
Attachment #146193 -
Flags: review?(neil.parkwaycc.co.uk) → review+
Comment 13•20 years ago
|
||
Comment on attachment 146193 [details] [diff] [review] bail at first rejection + observer.notify(cancelQuit, "quit-application-requested", null); sorry, that method is called observe. also, I don't think an exception from an observer should cancel the quit. (or should it?)
Attachment #146193 -
Flags: review+ → review-
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 14•16 years ago
|
||
timeless, Are you still working on this ?
Comment 15•12 years ago
|
||
> steal toolkit impl
we are now using Toolkit and toolkit's globalOverlay.js
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•