Despite the new name more accurately reflecting that the renderer process might be "gone" for many distinct reasons, by and large, render-process-gone is basically for the exact same same scenarios as what crashed used to be for -- either is for when the renderer process is gone, for whatever reason.

The new event exposes more specific reasons separately, but we don't need to use that new information if we don't want to, and I have some concern we're being too eager to make use of that more granular information as of this PR.

If I'm reading this new code correctly, it no-ops for all the following renderer process "goneness" reasons:

• clean-exit - Process exited with an exit code of zero
• abnormal-exit - Process exited with a non-zero exit code
• killed - Process was sent a SIGTERM or otherwise killed externally
• oom - Process ran out of memory
• launch-failed - Process never successfully launched
• integrity-failure - Windows code integrity checks failed

The new code only does anything on:

• crashed - Process crashed

(Note: render-process-gone potential reasons above were grabbed from the documentation you linked in the initial post of this PR: https://github.com/electron/electron/blob/9-x-y/docs/api/web-contents.md#event-crashed-deprecated)

I don't think it's worth having the distinction and if-gating what we do based on the "goneness" reason.

First of all, I'm not sure if no-oping and just not doing anything is safe to do in this situation? Continuing to run Atom with no renderer process? Isn't this a poorly defined app state that we should seek to quit from ASAP? Is there a point or advantage to not quitting (and not prompting the user to quit)? Have we thought it through, or is it just because the event no-longer specifically has the word crashed in the name, so it seemed appropriate from the name change alone?

And furthermore, if the process ran out of memory (reason: oom), and was terminated for that reason, is that so different from a crash? Most crash reporters I know of just treat it as another type of crash, not as a "non-crash". Is launch-failed, where the renderer process never started, a clean app state we should silently tolerate and do nothing about? If I manually kill the renderer process in a task manager or with the kill command, should Atom not do anything in response to that? Is abnormal-exit really so different from a crash? As far as I know, there is aways supposed to be a renderer process for Atom. As such, is clean-exit really okay? Just because there was no "error" sate reported by the renderer process upon exiting... I don't think we're supposed to be running without a renderer in general.

There might theoretically be some good, subtle uses of the various distinct reason values, in various places within the "renderer process gone" handling block. But it's worth identifying those and doing it in a deliberate and considered way, if at all. I'm not inclined to think putting the whole handler behind "if crashed" is the right approach though, as outlined above.