Patch: Crash: blocking JS alert and deleting a window

[Koos Vriezen]

On Mon, 28 Oct 2002, David Faure wrote:

> On Sunday 27 October 2002 14:04, Koos Vriezen wrote:
> > But again if we cannot control the destruction of KHTMLPart we're
> > lost. ~KHTMLPart is obviously too late for closing dialogs
> >
> > Ok, to summarize:
> > - KHTMLPart must be informed before destruction, where it can call
> >   closeChildDialogs()
> > - Some kind of reschedule, postEvent/deleteLater/timer, to allow the stack
> >   popping out of the dialog message loop.
>
> Doesn't it pop up immediately, with my new KDialogBase::cancel() call?
> ... much later, after doing some testing ...
> Ah, indeed it doesn't. exit_loop only sets a bool, it will only be used when
> the control goes back to the event loop.
>
> I agree with your summary then....

Would be quite messy if it weren't...

> Looking at the last patch, the one with EventFilterer.....
> The goal is to get the CloseEvent of the mainwindow, but due
> to the reparenting, you can't get hold of the mainwindow when
> the htmlview is created, right? (hence all that code with the
> Reparent event etc.)

Yes that's what I thought after grep'ing for 'reparent' in
kdebase/konqueror, but later I couldn't find the kdDebug output. I think
it simply can be removed, but it is to make sure we're monitoring to
toplevelWidget.

> This is why I was thinking of something slightly different:
> a new kind of event, which we'd define ourselves (like those defined
> in kparts/event.h). This event would be sent to konqueror's
> parts before destroying them.
> Hmm, I guess we could also simply send a CloseEvent, if Qt
> doesn't do it for non-toplevel-widgets?
> The point is that we could then simply write KHTMLView::closeEvent()
> instead of having to create an event filterer.

Maybe, but is konqueror active closing the mainwindow or just responding
to a X/WM close event. If so, the EventFilterer should be moved to
konqueror to get something like KHTMLView::closeEvent() working, which
doesn't reduce complexity than. Not to mention other hosts for KHTML...

Btw. if this is the only solution we can think of, we are still not done.
What about scripts like: 'alert(foo);alert(bar)' or
'eval("alert(foo)");alert(bar)'? KJS::Window should also be informed
not to spawn another message box.

Koos