Fix DELETE_EVENT handling in 3 places.

Fix DELETE_EVENT handling in 3 places.

(Still need to fix a few more after this.)

BUG=none
TEST=none

[Evan Stade, 2011-04-19 19:18:44]

it has come to my attention that on delete-event, GtkDialogs give the
DELETE_EVENT response and then destroy themselves. Previously I had thought that
DELETE_EVENT was the same as CANCEL, and we still needed to destroy. Hence we
are double destroying in a number of places.

Elliot, Tony: please review
Lei: FYI

[Elliot Glaysher, 2011-04-19 19:40:13]

LGTM

http://codereview.chromium.org/6873082/diff/2001/chrome/browser/ui/gtk/js_mod...
File chrome/browser/ui/gtk/js_modal_dialog_gtk.cc (right):

http://codereview.chromium.org/6873082/diff/2001/chrome/browser/ui/gtk/js_mod...
chrome/browser/ui/gtk/js_modal_dialog_gtk.cc:138: // NULL out |gtk_dialog_| when
it's destroyed.
Today I learn something about GTK.

[Evan Stade, 2011-04-19 21:51:24]

wait, crap. this doesn't work.

[Elliot Glaysher, 2011-04-20 17:37:50]

To possibly correct my mental model, was it gtk_widget_destroyed not working?

On Tue, Apr 19, 2011 at 2:51 PM,  <estade@chromium.org> wrote:
> wait, crap. this doesn't work.
>
> http://codereview.chromium.org/6873082/
>

[Evan Stade, 2011-04-20 18:38:57]

the delete-event triggers RESPONSE_DELETE_EVENT and *then* gtk_widget_destroy,
so in our destructor, dialog_ will always still be valid and we will call
gtk_widget_destroy. Then, the default delete-event handler will call
gtk_widget_destroy.

I think the easiest thing is just to override the delete-event handler to make
it do what we thought it did (i.e. not destroy).

[JKaterski, 2013-07-24 23:20:16]

lgtm