I've been having a weird issue with the SVN roundcube for a while. Sometimes a user logs in and then page just hangs. Can't click on anything: messages, folders, buttons, whatever. When this happens it is repeatable across different browsers and computers. It sometimes it seems to stop at a certain point (X number of messages down, cut off halfway across the page) and sometimes the page looks exactly right, but you can't do anything. Fixes have been largely inconsistent and range from changing the page size for the user (in the db since we can't do anything in browser) or moving mail out of their imap folder on the server, then moving it back. This has been very rare, probably rarer than 1 user in 20, but when it tends to happen to the same users again and again. Sometimes it'll go away after a day or so, then come back. I've tried copying user settings from working accounts and also tried comparing messages in affected accounts to find a pattern. So far, no dice. Anyone else having this problem or have a fix?
-Ryan Rittenhouse
On 6/5/07, Ryan Rittenhouse ryanmr@goshen.edu wrote:
I've been having a weird issue with the SVN roundcube for a while. Sometimes a user logs in and then page just hangs. Can't click on anything: messages, folders, buttons, whatever. When this happens it is repeatable across different browsers and computers. It sometimes it seems to stop at a certain point (X number of messages down, cut off halfway across the page) and sometimes the page looks exactly right, but you can't do anything. Fixes have been largely inconsistent and range from changing the page size for the user (in the db since we can't do anything in browser) or moving mail out of their imap folder on the server, then moving it back. This has been very rare, probably rarer than 1 user in 20, but when it tends to happen to the same users again and again. Sometimes it'll go away after a day or so, then come back. I've tried copying user settings from working accounts and also tried comparing messages in affected accounts to find a pattern. So far, no dice. Anyone else having this problem or have a fix?
I've experienced this on large mailboxes - especially those with (literally) a 100 folders. Could this be the case here?
Till
Not in most of the cases. The last three users to have this problem have less than 20 folders. I'm running up another RC installation with a seperate db to see if logging in on a clean slate makes a difference ... now I just have to wait until someone hits the bug again :p
-Ryan
Network Administrator Goshen College (574) 535-7004
till wrote:
On 6/5/07, Ryan Rittenhouse ryanmr@goshen.edu wrote:
I've been having a weird issue with the SVN roundcube for a while. Sometimes a user logs in and then page just hangs. Can't click on anything: messages, folders, buttons, whatever. When this happens it is repeatable across different browsers and computers. It sometimes it seems to stop at a certain point (X number of messages down, cut off halfway across the page) and sometimes the page looks exactly right, but you can't do anything. Fixes have been largely inconsistent and range from changing the page size for the user (in the db since we can't do anything in browser) or moving mail out of their imap folder on the server, then moving it back. This has been very rare, probably rarer than 1 user in 20, but when it tends to happen to the same users again and again. Sometimes it'll go away after a day or so, then come back. I've tried copying user settings from working accounts and also tried comparing messages in affected accounts to find a pattern. So far, no dice. Anyone else having this problem or have a fix?
I've experienced this on large mailboxes - especially those with (literally) a 100 folders. Could this be the case here?
Till
On 6/5/07, Ryan Rittenhouse ryanmr@goshen.edu wrote:
Not in most of the cases. The last three users to have this problem have less than 20 folders. I'm running up another RC installation with a seperate db to see if logging in on a clean slate makes a difference ... now I just have to wait until someone hits the bug again :p
Ok, for sure keep us posted. :)
Thanks for the help!
Till
hmm, i've seen and fixed this problem for our local installation, in an older version.
but the problem's reason may be different. We're using Turkish (as UTF-8), and in Turkish alphabet, uppercase of i is not I but a I with a dot (which makes it 2 bytes in UTF-8), and lowercase of I is not i but a i without a dot (which makes it 2 bytes, again).
hmm, i should have reported this bug in trac, but i'm not sure, i can't find it now, probably i didn't. anyway, here's what i did to fix it (digging the sources now for the changes i've made)
well, i've fixed the issue in rev508, and we're still using that revision. the problem was in program/include/rcube_db.inc , with all the search&replaces using rc_strtolower().
well, the bug works in this way; for placing of ending javascripts, rcmail searches for the starting position of "</head>" string in the final html. these javascripts "enable" the buttons in the UI, as far as i remember, setting something like "block_controls = false" (although i don't remember the name). Well, rcmail does
if($hpos = rc_strpos(rc_strtolower($output), '</head>'))
As it used rc_strtolower, in an alphabet like ours, byte counts are changed (when uppercase i is converted to lowercase), and $hpos now shows a position in the lowercase version of the html, and it is the wrong position in the original one. then the javascript is inserted into that position in the original html, and what we get is a javascript code inside </head> splitting it in two.
i've made the change, instead of using rc_strtolower(), i use strtolower(), which IGNORES encoding information, and also, does not change byte counts. It just lowers the string "</HEAD>", and a strpos can find it in the correct position that way. As long as the searched string does not contain a non-ascii character (well, "</head>" doesn't), this doesn't cause encoding-related problems.
This fixed our all hangup problems, and it doesn't hangup anymore. At least speaking for svn rev508.
hope that helps, -Kerem HADIMLI
On 6/5/07, till klimpong@gmail.com wrote:
On 6/5/07, Ryan Rittenhouse ryanmr@goshen.edu wrote:
Not in most of the cases. The last three users to have this problem have less than 20 folders. I'm running up another RC installation with a seperate db to see if logging in on a clean slate makes a difference ... now I just have to wait until someone hits the bug again :p
Ok, for sure keep us posted. :)
Thanks for the help!
Till
oh, it is not in rcube_db.inc, it's in rcube_shared.inc, sorry :)
This is the diff of svn rev508 and my modified version (comments are in Turkish ) :
177a178,179
// rc_strtolower, multibyte çalýþýnca bozabiliyor pozisyonlarý
179c181
if($hpos = rc_strpos(strtolower($output), '</head>'))
184,185c186,187 < $hpos = rc_strpos(rc_strtolower($output), '<body'); < if (!is_numeric($hpos) && ($hpos = rc_strpos(rc_strtolower($output), '<html')))
$hpos = rc_strpos(strtolower($output), '<body'); if (!is_numeric($hpos) && ($hpos = rc_strpos(strtolower($output), '<html')))
203c205
if($bpos = rc_strpos(strtolower($output), '<body'))
209c211
$bpos = rc_strpos(strtolower($output), '</head>')+7;
215a218,219
// bugfix. rc_strtolower, stringin boyutunu bozuyor (utf8 ise sanýrým). sonra yanlýs yere insert ediliyor
217c221
$output_lc = strtolower($output);
regards, -Kerem HADIMLI
On 6/8/07, Kerem Hadimli wastiee@gmail.com wrote:
hmm, i've seen and fixed this problem for our local installation, in an older version.
but the problem's reason may be different. We're using Turkish (as UTF-8), and in Turkish alphabet, uppercase of i is not I but a I with a dot (which makes it 2 bytes in UTF-8), and lowercase of I is not i but a i without a dot (which makes it 2 bytes, again).
hmm, i should have reported this bug in trac, but i'm not sure, i can't find it now, probably i didn't. anyway, here's what i did to fix it (digging the sources now for the changes i've made)
well, i've fixed the issue in rev508, and we're still using that revision. the problem was in program/include/rcube_db.inc , with all the search&replaces using rc_strtolower().
well, the bug works in this way; for placing of ending javascripts, rcmail searches for the starting position of "</head>" string in the final html. these javascripts "enable" the buttons in the UI, as far as i remember, setting something like "block_controls = false" (although i don't remember the name). Well, rcmail does
if($hpos = rc_strpos(rc_strtolower($output), '</head>'))
As it used rc_strtolower, in an alphabet like ours, byte counts are changed (when uppercase i is converted to lowercase), and $hpos now shows a position in the lowercase version of the html, and it is the wrong position in the original one. then the javascript is inserted into that position in the original html, and what we get is a javascript code inside </head> splitting it in two.
i've made the change, instead of using rc_strtolower(), i use strtolower(), which IGNORES encoding information, and also, does not change byte counts. It just lowers the string "</HEAD>", and a strpos can find it in the correct position that way. As long as the searched string does not contain a non-ascii character (well, "</head>" doesn't), this doesn't cause encoding-related problems.
This fixed our all hangup problems, and it doesn't hangup anymore. At least speaking for svn rev508.
hope that helps, -Kerem HADIMLI
On 6/5/07, till klimpong@gmail.com wrote:
On 6/5/07, Ryan Rittenhouse ryanmr@goshen.edu wrote:
Not in most of the cases. The last three users to have this problem have less than 20 folders. I'm running up another RC installation with a seperate db to see if logging in on a clean slate makes a difference ... now I just have to wait until someone hits the bug again :p
Ok, for sure keep us posted. :)
Thanks for the help!
Till