Patch: Crash: blocking JS alert and deleting a window

[Koos Vriezen]

On Sun, 27 Oct 2002, David Faure wrote:

> On Saturday 26 October 2002 17:21, Koos Vriezen wrote:
> > Solving this first case, other than blaming Qt for sending a CloseEvent to
> > a window that has a modal dialog, means
> > - the part has to be informed that it will be destroyed and the part
> >   should be deleted with deleteLater (way isn't deleteLater virtual?), or
>
> deleteLater is going to cause heaps of other problems (the destruction
> code relies on the part destroying the widget, etc.)
> But we could still inform the part that it's going to be destroyed.
>
> > Looks like we can't override deleteLater but, but since it post a
> > DeferredDelete event, it can be filtered, call
> > KHTMLView::closeChildDialogs and call deleteLater again (not doing the
> > same the next time of course).
> >
> > bool KHTMLPart::event ( QEvent * e ) {
> >   if (e->type () == QEvent::DeferredDelete && !d->m_delayDelete) {
> >     if ( d->m_view )
> >       d->m_view->closeChildDialogs();
> >     d->m_delayDelete = true;
> >     deleteLater();
> >     return true;
> >   }
> >   return false;
> > }
>
> We could do the same with our own event definition (defined in kparts/) ....

Any particular event in mind? Should we catch the CloseEvent of
KParts::MainWindow and post a new one after calling closeChildDialogs()?

> > should do it (also adding bool m_delayDelete). Unfortunately the above
> > test case still crashes because
> > #0  0x4152c978 in KHTMLView::~KHTMLView() ()
> > #1  0x40b19b40 in QWidget::~QWidget() ()
> > #2  0x4009d391 in KonqFrame::~KonqFrame() ()
> > #3  0x40b19b40 in QWidget::~QWidget() ()
> > #4  0x40bbc13d in QMainWindow::~QMainWindow() ()
> > #5  0x4059b077 in KMainWindow::~KMainWindow() ()
> > #6  0x4017ba2e in KParts::MainWindow::~MainWindow() ()
> > #7  0x4005bfe1 in KonqMainWindow::~KonqMainWindow() ()
> > #8  0x40aed150 in QObject::event(QEvent*) (
> >
> > still happens in the dialogs message loop (and the tokenizer is still
> > running). Ok KPart::slotWidgetDestroyed() also deletes the part,
>
> Yes. We can't change the destruction mechanism of KParts.
> However all we want here is to call closeChildDialogs() at the right time....
> I'm not fully seeing the problem here. Both ~KHTMLView and ~KHTMLPart
> call closeChildDialogs. Hmm, maybe ~KHTMLPart should simply call it earlier?
> As long as we close the dialog before destroying anything else it might return to
> (i.e. KHTML's part, view, DOM tree, JS stuff etc.), it should be fine, no?

But again if we cannot control the destruction of KHTMLPart we're
lost. ~KHTMLPart is obviously too late for closing dialogs (that's why I
didn't erase my second option, every non event call from khtml to kjs
passes KHTMLPart, but it's too big of a change to implement it).

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.
- Real destruction of KHTMLPart

Koos