Keep a crashed app's window around after crashing
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Apport |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
When an app crashes, its window disappears. At some later point (although as soon as possible, of course) apport shows an alert (as per https:/
The (inevitable) gap between the app crashing (its window(s)) disappearing) and the apport alert means that there is a disconnect between the two things. This gap may be short, but in my experience it is long enough for me to feel frustration that my app has crashed, to start thinking about what I can do about that, to start the process of restarting the app, and then to be disturbed in that process by the apport alert. (In practice, I've often managed to successfully restart the app myself before apport shows the alert.)
This disconnect could be alleviated by continuing to display an app's window even after it has crashed. The apport alert could then be modal to this app window, or possibly even drawn directly into this app's window, thus maintaining the mental connection and continuity between the application and the alert telling you that it has crashed.
A visual mockup idea, showing the window fading to red (similar to the fade-to-grey for hung apps, but different in colour because this app will definitely not come back) and then apport drawing its alert onto this dead window, is attached.
Implementation notes: obviously, when an app crashes, its windows go away (there is no app there to provide them). So this "red" window would be a fake of some kind, provided by some other process. One approach may be for compiz to keep the texture for the window around; to continue to display that texture (as a "fake window") even after it receives a DestroyWindow; and for apport, when it starts up, to display a window of its own with the same size and position and to ask compiz for the texture, so that apport can display that texture itself (and at that point the "fake window" is a real window again). There are all sorts of potential complexities and race conditions and stacking issues with "fake windows" here, but smspillaz suggests that whoever implements this ought to be able to do something like this. These notes do not dictate how the idea should be implemented; they are merely ideas.
| Stuart Langridge (sil) wrote | #1 |
| Stuart Langridge (sil) wrote | #2 |
| Changed in apport: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
Some notes from smspillaz on how it might be implemented, for whoever (not smspillaz) would be doing the implementation:
12:33:10 <aquarius> How possible would it be for compiz (or possibly something else in the graphics stack) to keep a picture of an app's window around for a bit after that app crashes?
12:33:35 <smspillaz> perfectly possible
12:33:55 <smspillaz> well, compiz would be able to
12:34:15 <smspillaz> it just might get a bit weird though because you're managing a window that doesn't exist
12:34:19 <aquarius> so, if an app crashes (and thus the process exits), compiz could continue to show its window as though it had not crashed (although obviously that window would not be interactive)
12:34:24 <smspillaz> so I can forsee running into lots of really small problems
12:34:38 <aquarius> yeah, this is why I'm asking you about it :0
12:34:42 <aquarius> I had this idea, you see:
12:34:43 <smspillaz> it would be able to show its window, I don't think we'd be able to handle things like raising it and lowering it from it scurrent position in the stack sanely
12:34:56 <smspillaz> it would have to stay at the top
12:35:02 <aquarius> when an app crashes, apport kicks in and five seconds later you get the apport crash dialog
12:35:37 <aquarius> what I'd *like* to happen is that an app crashes, its window goes grey (or maybe, I don't know, red or something) and then apport draws the crash dialog into the crashed window
12:35:54 <smspillaz> oh ok, the drawing into the crashed window bit is where you're going to run into trouble
12:36:11 <aquarius> so the crash dialog isn't saying "that app that was running five seconds ago crashed", and it's not even saying "that app over there crashed", it's saying "this app right here crashed".
12:36:22 <smspillaz> right I see what you mean
12:36:57 <smspillaz> you'd have to have some kind of apport plugin for compiz to handle that case though
12:37:07 <aquarius> I had this thought: app crashes, compiz says "aha, a crashed app, I will continue to display its window for a bit", apport starts up, apport creates its *own* window at the same size and position, compiz says "here is the texture from the crashed app", apport displays that, compiz forgets about the texture
12:37:33 <aquarius> so there's a brief time window (in between app segv and apport creating a window) in whcih compiz is managing a window for no app, but it's short
12:37:47 <aquarius> and then after that it's all apport and compiz can forget about it
12:37:58 <smspillaz> right, so its doable but there are three parts about this that are decidedly nontrivial
12:39:18 <smspillaz> okay so the first one is that there's a race between getting the notification that the application crashed as opposed to the window recieving a DestroyNotify from the server
12:39:31 <smspillaz> if the latter happens first compiz will just play the close animation
12:39:49 <smspillaz> we'd need some kind of synchronization there
12:40:14 <smspillaz> the server doesn't tell you why a window was destroyed
12:40:19 <smspillaz> it just tells you that its destroyed
12:4...