Patch: Crash: blocking JS alert and deleting a window

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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/) ....

> 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?

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9u7CN72KcVAmwbhARAmlaAJ9ZlCkoEStkMkGuXV70q61wpxaWNgCfe/bb
o6daPredJ5A7QY9Kuqjw/+Y=
=UWFL
-----END PGP SIGNATURE-----