Crash: blocking JS and deleting a window

Wed Oct 2 20:24:08 BST 2002

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

Koos