JS freeze dialog and google mail

Hi,

Lately I sometimes get the JS freeze dialog w/ google mail,
and worse,
not one but six or seven of them. Now I think a quick fix
is:

--- interpreter.cpp     (revision 606114)
+++ interpreter.cpp     (working copy)
 -381,9
+381,9 
 bool ExecState::hadException()
 {
   if (terminate_request) {
+    terminate_request = false;
     if (confirmTerminate())
       _exception = Error::create((ExecState*)this);
-    terminate_request = false;
   }
   return _exception.isValid();
 }

because timers still occur in this dialog event loop and
will hit this
terminiate_request. I think a more advanced fix, eg.
delaying all
timers when this dialog is up, is a bit too complicated as
we have to
check every Window object (although w/ intervals, one could
still have
many dialogs after a bathroom visit).

This extra CPU power needed lately may be of gmail
'enhancements' or
some unfortunate commit in KHTML. It does seem to get slower
in time,
esp. closing the gmail tab becomes really slow, depending
how much
gmail was used (as it seems).
What does worry me is that not long ago, I could have
konqueror
running for weeks, and these days I restart konqueror almost
every
day, because the memory use becomes so high.

Koos

> Hi,
>
> Lately I sometimes get the JS freeze dialog w/ google
mail, and worse,
> not one but six or seven of them. Now I think a quick
fix is:

It would be nice if you get a gdb backtrace for the konq
process when that
happens

>
> --- interpreter.cpp     (revision 606114)
> +++ interpreter.cpp     (working copy)
>  -381,9 +381,9 
>  bool ExecState::hadException()
>  {
>    if (terminate_request) {
> +    terminate_request = false;
>      if (confirmTerminate())
>        _exception = Error::create((ExecState*)this);
> -    terminate_request = false;
>    }
>    return _exception.isValid();
>  }
>
> because timers still occur in this dialog event loop
and will hit this
> terminiate_request.

Looks good to me....

> I think a more advanced fix, eg. delaying all
> timers when this dialog is up, is a bit too complicated
as we have to
> check every Window object (although w/ intervals, one
could still have
> many dialogs after a bathroom visit).

Long-term, we have to do something like that, since one gets
nasty
recursion issues with things like alert() as well..

> This extra CPU power needed lately may be of gmail
'enhancements' or
> some unfortunate commit in KHTML. It does seem to get
slower in time,
> esp. closing the gmail tab becomes really slow,
depending how much
> gmail was used (as it seems).
> What does worry me is that not long ago, I could have
konqueror
> running for weeks, and these days I restart konqueror
almost every
> day, because the memory use becomes so high.

Ouch, but that's something that just has to be debugged,and
there is no
easy way of doing it.. (Well, valgrind is one, but it's
probably too slow)

2006/11/19, Maksim Orlovich <mo85cornell.edu>:
> > Hi,
> >
> > Lately I sometimes get the JS freeze dialog w/
google mail, and worse,
> > not one but six or seven of them. Now I think a
quick fix is:
>
> It would be nice if you get a gdb backtrace for the
konq process when that
> happens

Only hard to reproduce when waiting for it. Till now I only
had one
such case, but with patch below.

> > --- interpreter.cpp     (revision 606114)
> > +++ interpreter.cpp     (working copy)
> >  -381,9 +381,9 
> >  bool ExecState::hadException()
> >  {
> >    if (terminate_request) {
> > +    terminate_request = false;
> >      if (confirmTerminate())
> >        _exception =
Error::create((ExecState*)this);
> > -    terminate_request = false;
> >    }
> >    return _exception.isValid();
> >  }
> >
> > because timers still occur in this dialog event
loop and will hit this
> > terminiate_request.
>
> Looks good to me....

Thanks, I'll commit it later ..

> > I think a more advanced fix, eg. delaying all
> > timers when this dialog is up, is a bit too
complicated as we have to
> > check every Window object (although w/ intervals,
one could still have
> > many dialogs after a bathroom visit).
>
> Long-term, we have to do something like that, since one
gets nasty
> recursion issues with things like alert() as well..

Well if the other browsers don't do timer events during
this, then
khtml should do it probably too (and httpXmlRequest results
and what
more) ..

> > This extra CPU power needed lately may be of gmail
'enhancements' or
> > some unfortunate commit in KHTML. It does seem to
get slower in time,
> > esp. closing the gmail tab becomes really slow,
depending how much
> > gmail was used (as it seems).
> > What does worry me is that not long ago, I could
have konqueror
> > running for weeks, and these days I restart
konqueror almost every
> > day, because the memory use becomes so high.
>
> Ouch, but that's something that just has to be
debugged,and there is no
> easy way of doing it.. (Well, valgrind is one, but it's
probably too slow)

Actually this maybe false alarm (gmail). I've used other web
apps
lately, and maybe one of those were the cause. At least this
week I'm
still running the same konqueror..

Koos