Critical memory leaking and freezing caused in firefox 3

I ´m experiencing a similar problem but using the 5.x-1.x-dev version: FF freezing for several seconds before loading a page that has l10n_client widget, memory consumption double very quickly and when comes back reports that jquery.js is taking too much time to execute and ask whether to stop, debug, continue?.
Same problem on IE.
I have installed the jquery_update module.

i've got performance issues with firefox 3.x too. i don't know if it's related to memory consumption
but i'm asked to stop the script too after some seconds of browser freezing.

i think it's related to the huge amount of strings that are being processed by the script.

maybe a (complex) solution it's to load only a small set of the string to be translated first,
then load the other strings _while scrolling the list (with some kind of ajax) to reduce startup time.

I´ve just came to same thought today: loading string data in small chunks using an ajax on-demand scroller thing should possibly solve this issue.

Same problems here. FF is ~20 seconds unresponsive, CPU spikes to 80-90% and nothing can be done.

In my case I discovered the string data contains the set for the entire site i.s.o. just the ones in the requested page, that´s why the CPU and memory consumption blew up.

There is a special 'locale_cache_strings' variable used inside locale.module to manage caching for the translatable strings in a request, a value of 0 would mean no caching. The l10n_client_init() hook implementation seems to take care of this, but somehow it is not working for me, so I have manually setted 'locale_cache_strings' to 0 and it wokrs now!.

I haven´t figured out why isn´t hook_init() working in my case ...

So, as a workaround, you may set this variable value to 0 fixed it, e.g.

  variable_set('locale_cache_strings' , 0);

but beware, doing this may cause performance issues in your site so use with caution!

Well, would be good to verify whether others had the init hook not running well or some other problem. And if the init hook is the culprit, then we can put our heads together and debug that finally :)

To get string data directly from database the l10n_client_init() must be called at the very beginning before any call to t() is made, otherwise the translatable strings will end retrieved from cache (code in locale() takes care of it).

In my case, another module´s hook_init, invoked before l10n_client_init(), is itself calling t() ..... then string data is filled with several thousands from cache.

So, to get the appropiate calling order I changed l10n_client module weight to the lowest, this fixed the issue. This is not *obvious* in the documentation, guess it is a bug ... ?

I´m using the 5.x version, and haven´t checked the 6.x code!!

Hope this helps!

patricio: great analysis!

What we can do to avoid fiddling with weights is to reset the locale() cache in l10n_client_init() via locale(NULL, NULL, TRUE); and let it start from there. That would loose us the one or two t() strings from other module's init hooks, but make this universally work and avoid freezing.

Thanks Gábor.

Reseting cache as you proposed seems ok, on 5.x gets a little trickier as it not possible to reset the cache in locale(), maybe we need to add that possibility in the current patch for locale.

To avoid manually struggling with module´s weight perhaps it can auto-set its weight to the lowest on activation? I guess this is feasible but would you recommed doing so? maybe it should also needs to self-check its weight on a regular basis ... as if taking a weight loss diet :)

Let's try this one and see whether there are actually loosing any useful strings this way. Patch against Drupal 6.x-dev. If this solves the issue, we can look into backporting it to Drupal 5 via an updated core patch as well.

Committed to 6.x-1.x, to be ported to 5.x.

THX, seems now really fast and no more locking up the browser :-)

i am having the same problem in my site with your module and when i leave the drupal modules page.
in this last case, you get a popup window saying when leaving the page.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://drupal.org/files/js/6054cc4e256e8cec7cca8fab0cb55fbc.js:13

i am on a ubuntu hardy with firefox 3

and thanks a lot for the module: makes transllation easyer :)

Experiencing the same issue. See also:
http://drupal.org/node/419392

@ErwanF: well the report of slowness in itself is not too useful. Are you using too many modules (too many strings to translate), a generally slow computer or have any other details which might help identify the underlying issue. The issue reported above was fixed, so this might be a new problem which should be moved to a new issue then (unless it is a problem with your local environment, in which case, we cannot help).

same here... i have 6 languages activated on the website and firefox consumes up to 400mb (!), freezes and takes ages to come back.
is the patch commited already?
deactivating localization client removes the problem immediately
I use the current drupal 6 version

hello

i came to see if i can give more info in this issue.
i keep getting this message on http://drupal.org/node/206666 (alphabetic list of modules) when i try to close or leave it.
what other info would you need?

I'm having a similar problem working with menu administration once the number of menus reaches a moderate size.

We're running Drupal 6.12 on a remote server with Apache 2.2 and I'm running Firefox 3.0.11 under Windows XP at the client end. When I try to admin a custom menu that has 377 items, I consistently get a jquery.js script taking too much time to execute message: stop or continue. CPU usage shoots up to 80% and FF memory jumps from 135K to 400K. I press continue once and that usually is enough to complete the script.

Our custom menus will contain up to several thousand items, so this problem will not go away for us, unless we redesign.

I've tried running Chrome 2.0.172.33 under XP and didn't get the message. CPU usage shot up to 70% but Chrome memory did not change significantly.

Chris

David Humphrey suggested that I try FF 3.5 beta. Thanks Dave.

The CPU usage is down to 60% from 80% and the memory only shoots up from 123K to 172K, all of which are quite an improvement. Elapsed time is significantly improved. However, the jquery.js message now appears twice before settlement.

Chris

No new updates in 10 months, so I assume browser updates resolved your issues.