If a JavaFX event handler calls close() on a stage while processing an OS message (like a key press) there will be a period of time where the Glass code is referencing members of a C++ object that has been deleted. The sequence is:

- Glass receives an OS message and processes it inside GlassWindow::WindowProc. This typically calls some other handling routine (e.g. HandleViewKeyEvent) before optionally sending the message to ::DefWindowProc.
- Glass notifies the Java code of the event which generates an FX Event.
- An FX event handler calls close() on the Stage.
- Glass immediately calls delete on the GlassWindow and GlassView peer objects.

From that point onward the (possibly nested) calls to GlassWindow::WindowProc and all of the handling code will be referencing freed memory.

To reproduce:
Build JFX using the DebugNative configuration (-PCONF=DebugNative)
Run the attached SegFault.java test
Press Delete to close the stage

Actual result:
The app will quit with a segmentation fault.

Expected result:
A clean exit

(For the Delete key the glass code sends PRESSED and TYPED events back-to-back. The PRESSED event causes the WindowContext to be destroyed so it's referencing freed memory when sending the TYPED event.)