RoundCube forces me to kill FireFox

till klimpong at
Sun Jul 8 21:04:13 CEST 2007

On 7/7/07, David Abrahams <dave at> wrote:
> on Fri Jul 06 2007, Jim Pingle <> wrote:
> > David Abrahams wrote:
> >>> 0.1-rc1.1 ;-)
> >>>
> >>> Yes, that's what I mean - please give it a try. Also if you can, test
> >>> against trunk.
> >>
> >> yes, with both those versions, httpd starts to chew up a steadily
> >> increasing percentage of CPU (it was at 98% within 30 sec).  Firefox
> >> locks up and needs to be killed.  After killing firefox, httpd
> >> *very* gradually reduces its CPU load, then seems to hover around 50%
> >> for a while, then finally gives up and goes back close to
> >> zero... so I don't have to kill my server; I do have to kill FireFox.
> >>
> >> It looks from the outside like roundcube's JavaScript is trying to ask
> >> the server some big question before it will allow the browser display
> >> to update.
> >
> > It might be somewhat hard to pick out the traffic, but have you tried
> > watching the connection with a tool such as tcpflow? It would let you
> > monitor what exactly is being communicated back and forth while the CPU load
> > is high and FF is locked up.
> >
> > I wonder if it's held up waiting on something, or if it is actually
> > transferring data at that point. Either way you should be able to capture
> > the last (few?) request(s) up to the point where it fails. That may go a
> > long way toward figuring out where the problem lies...
> There's hardly any traffic during that period.  Unfortunately it's a
> bit hard to see what's going on over an https:// connection by looking
> at tcpflow. :(

Of course you would need to turn off SSL. :-) So maybe set up a second
RC version (from SVN) and see if it behaves the same.

I've seen some issues too when you have plenty of folders, large
mailboxes - but I never ever had to restart Firefox. Sometimes there
is a little "hang" when the folders are scanned for unread but aside
from that, nothing major.


More information about the Dev mailing list