Closed Bug 238391 Opened 20 years ago Closed 12 years ago

quit-application-requested should support cancelling

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: timeless, Assigned: timeless)

References

Details

Attachments

(1 file, 2 obsolete files)

 
Attached patch steal toolkit impl (obsolete) — Splinter Review
Attachment #144582 - Flags: review?(neil.parkwaycc.co.uk)
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.
FWIW this way is more compatible with FF too ;-)
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
Attached patch honor toolkit api (obsolete) — Splinter Review
Attachment #144582 - Attachment is obsolete: true
Attachment #144750 - Flags: review?(neil.parkwaycc.co.uk)
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-
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)
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 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 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 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-
Product: Core → Mozilla Application Suite
timeless,
Are you still working on this ?
Component: XP Apps: GUI Features → UI Design
> 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.

Attachment

General

Creator:
Created:
Updated:
Size: