Crash: blocking JS and deleting a window
Simon Hausmann
hausmann at kde.org
Fri Oct 4 13:20:24 BST 2002
On Fri, Oct 04, 2002 at 01:42:53PM +0200, Koos Vriezen wrote:
> On Fri, 4 Oct 2002, Simon Hausmann wrote:
>
> > On Thu, Oct 03, 2002 at 09:17:53PM +0200, Koos Vriezen wrote:
> > > On Wed, 2 Oct 2002, Simon Hausmann wrote:
> > >
> > > > > On Wed, 2 Oct 2002, Simon Hausmann wrote:
> > > > > >
> > > > > > 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.
> > >
> > > Does the attached patch for kparts implements what you mean?
> >
> > In general, yes :) On the BE side I was thinking of providing the
> > event class based on KParts::event (makes testing for the event
> > easier and prevents possible conflicts with other custom events) as
> > well as re-implementing customEvent instead of making BEPriv inherit
> > from QObject and using an eventFilter. I'll see about doing that
> > part this weekend (including the Konq side) , unless someone beats
> > me to it :)
>
> Great! If you mean by Konq the khtml part also, note that
> 'm_script_active' in my patch should be a counter not a bool. (Maybe
> using KJS::InterpreterImp::recursion for it, however this doesn't
> increment on events...needs something for that too)
With Konq side I meant the side that actually sends the event :)
I'll leave the khtmlpart part to you then (I'm not familiar with the
javascript thing :)
Simon
More information about the kfm-devel
mailing list