Crash: blocking JS and deleting a window

Simon Hausmann hausmann at kde.org
Wed Oct 2 20:47:00 BST 2002


On Wed, Oct 02, 2002 at 09:24:08PM +0200, Koos Vriezen wrote:
> On Wed, 2 Oct 2002, Simon Hausmann wrote:
> 
> > On Wed, Oct 02, 2002 at 08:44:16PM +0200, Koos Vriezen wrote:
> > > Hi,
> > >
> > > Testcase:
> > >
> > > <html><head><script>
> > >   var win=open("", "xxx");
> > >   var doc=win.document;
> > >   doc.open();
> > >   doc.write("<html><body onLoad=\"alert(somevar)\">");
> > >   doc.write("</body></html>");
> > >   doc.close();
> > > </script></head>
> > > <body></body></html>
> > >
> > > After the second window is created, delete it by clicking the X button.
> > > Even KCrash crashes on this one.
> > > The problem is blocking JS (here the alert box, might as well be a
> > > LiveConnect call). Currently I see these options:
> > > - Konqueror should delete a View after verifying it can. In this case,
> > >   with the alert box, it should poll the view if it can
> > >   be deleted. Probably requires quite some changes for this.
> > > - KHTML or KJSProxy should block somehow the deletion calling chain. Eg.
> > >   while(notfinished) { usleep(20000); qApp->processEvents(100); }
> > >   (which is a rather poor attempt to synchronize these calling chains.
> > >   It also doesn't work. With the processEvent, a timerEvent in KHTMLView
> > >   causes another crash. Without, there is no way to click away the alert
> > >   box).
> > > - Make sure the X button doesn't work when doing JS :)
> > >
> > > Anyone have any thoughts on this?
> >
> > We could do it like Qt does: Send a (custom) event to say the BE
> > object and ask it to accept/ignore it (by letting the custom event
> > class provide an accept/ingore API like many of the Qt events) . The
> > default implementation could just acept it.
> >
> > Depending on the result Konq could accept/ignore the close event it
> > receives.
> 
> Sounds good, KHTML could check if some JS is active. Am I correct that
> between accepting this event and the actual deletion, a timer event could
> still occur? (which means all scheduled scripts should be canceled before
> accepting that event, same for UI events, Java events, ...)

I was thinking of immediate deletion.

Simon




More information about the kfm-devel mailing list