[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Patch: Crash: blocking JS alert and deleting a window
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-10-22 8:46:10
[Download RAW message or body]

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

On Monday 21 October 2002 22:52, Koos Vriezen wrote:
> Ok, this is the stack when the message box is still shown:
> KMessageBox::questionYesNo(QWidget*, ....)
> khtml::RenderPartObject::slotPartLoadingErrorNotify()
> khtml::RenderPartObject::partLoadingErrorNotify(khtml::ChildFrame*, ....)
> KHTMLPart::processObjectRequest(khtml::ChildFrame*, KURL const&, QString const&)
> KHTMLPart::requestObject(khtml::ChildFrame*, KURL const&, KParts::URLArgs const&)
> khtml::RenderPartObject::partLoadingErrorNotify(khtml::ChildFrame*, ....)
> KHTMLPart::processObjectRequest(khtml::ChildFrame*, KURL const&, QString const&)
> KHTMLRun::foundMimeType(QString const&)
> KParts::BrowserRun::slotBrowserMimetype(KIO::Job*, QString const&)
> KParts::BrowserRun::qt_invoke(int, QUObject*)
> KHTMLRun::qt_invoke(int, QUObject*)
> QObject::activate_signal(QConnectionList*, QUObject*)
> KIO::TransferJob::mimetype(KIO::Job*, QString const&)
> 
> Didn't debug it, but looking at the source KHTMLPart::requestObject(...)
> does a child->m_run->abort(), which schedules a 'delete this'. The timer
> event will occur in the dialog message loop, so a crash occurs in
> KParts::BrowserRun after it returns there.

Ah, good one. abort() assumes we will return from KHTMLRun's methods before
the 0-timer is triggered. Not the case here, due to the msg box.
Ah, and this looks like the activex code - partLoadingErrorNotify makes
another try at requestObject, with another mimetype.

Hmm, I don't get it - why does partLoadingErrorNotify call slotPartLoadingErrorNotify
_TWICE_ ? Looks like I tried the 0-timer there, Dirk added the "put the tokenizer on hold",
but one of us forgot to remove the other's code. This explains the double dialogs
we were getting (before the pluginPageQuestionAsked() fix) !

I think the fix for this crash would be to comment out the 
setOnHold(false) / direct call / setOnHold(true)
and go back to the 0-timer solution. Can't remember any drawback of that approach,
except that so many 0-timers in the code are getting hard to debug.
But here it's about popping up a msg box and if 'yes', a new window, so it's
rather unrelated to the rest.

My suggested patch, then:

Index: render_frames.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/rendering/render_frames.cpp,v
retrieving revision 1.143
diff -u -p -r1.143 render_frames.cpp
- --- render_frames.cpp   2002/10/17 02:29:50     1.143
+++ render_frames.cpp   2002/10/22 08:45:59
@@ -767,10 +767,12 @@ bool RenderPartObject::partLoadingErrorN
     // Dissociate ourselves from the current event loop (to prevent crashes
     // due to the message box staying up)
     QTimer::singleShot( 0, this, SLOT( slotPartLoadingErrorNotify() ) );
+#if 0
     Tokenizer *tokenizer = static_cast<DOM::DocumentImpl *>(part->document().handle())->tokenizer();
     if (tokenizer) tokenizer->setOnHold( true );
     slotPartLoadingErrorNotify();
     if (tokenizer) tokenizer->setOnHold( false );
+#endif
     return false;
 }

- -- 
David FAURE, david@mandrakesoft.com, faure@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)

iD8DBQE9tRBS72KcVAmwbhARAn0kAJ0ZzFnWYmiBwjokn+iQb1KeTB7PTgCfUqfb
iZQ36rfx4vKB0Z8UNuTel8U=
=dxj6
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]