Roundcube inbox hangs a lot

[Cthulhu]

Hello everyone.
This is my first time posting in this forum, so first, thanks for this nice piece of software.

I've been facing a problem with my roundcube installation for 2 days now : whenever I try to read my mails, roundcube hangs a lot, especially in the inbox but also in other folders, displaying nothing while searching for message, then most of the time it says there is new messages but does not diplay them, only old ones.
I keep having this message in the errors log since this problem appears : "PHP Warning:  fgets(): SSL read operation timed out in /home3/carcel/public_html/roundcube/program/lib/Roundcube/rcube_imap_generic.php on line 200".

I tried to deactivate all my plugins (the first symptom was the filter plugin stop working), to see if the last update conflicted with one of them, without success. It still hangs.
For information : I am on a shared web hosting service. They have their own installation of roundcube which work perfectly fine, so the problem doesn't seem to come from the hosting, but it is still in version 1.0.0 and doesn't allow plugin installation (the reason why I use my own installation).

I did a quick search on this forum to see if other people had this same issue once, but my english is far from perfect, I hope I did not miss a particular keyword in my search that would have lead me to the right topic.

Many thanks.

[alec]

Last PHP version (5.4.33 and 5.5.17) is broken. Downgrade.

[Cthulhu]

Arf. Thanks for the info. I will see with my hosting service (as it is a sharing one, I don't have any control on it).
Thanks for the answer.

[Cthulhu]

I changed for PHP 5.3 until 5.4/5.5 are fixed, I can confirm the problems are gone. Thanks again for the help.

[t88462]

Just to be clear: so the php version being "broken", will cause the lower half of the screen (after logging in) to remain empty?
I am using Debian stable (wheezy, which includes php 5.4.4-14+deb7u14).

Since I upgraded 1.0.1 to 1.0.3 upon logging in, the "loading" message stays active. Eventually it seems to time out, and the bottom part stays empty.
When I click an email, it does not load in the bottom part.
When I double click the email, a new window correctly showing the mail is opened.
When I click "delete" there, the mail is effectively deleted. When I use the "delete" icon/button from the main page, nothing happens.

When I try to attach files, I receive a popup saying "an error occured! File upload failed.". IF I go ahead and send the mail to myself, "sending message" keeps being shown, pretty much the same way "loading" is displayed. Nothing seems to happen, until I close (and "leave page") that new window.
HOWEVER. The mail got sent, the attachment is received succesfully.

Is this caused by the same issue? I've been reviewing file permissions and reconfiguring nearly constantly to try and get this resolved.
Oddly enough, there was a point yesterday when this issue was not occuring, but I can't mimic the right settings/situation anymore.

None of the logfiles point at anything helpful.

[t88462]

I should add: in my despair I've enabled the installer, just so that I could go to "test config".
Everything is shown as green/OK.

Check config file
defaults.inc.php:  OK
config.inc.php:  OK
Check if directories are writable

Roundcube may need to write/save files into these directories
temp/:  OK
logs/:  OK
Check DB config
DSN (write):  OK
DB Schema:  OK
DB Write:  OK
DB Time:  OK
Test filetype detection
Fileinfo/mime_content_type configuration:  OK
Mimetype to file extension mapping:  OK

Mail is received and can be replied to.
I just can't get the "loading" message to disappear, nor can get this to work like before.

Composing and replying to mail are broken:
1/ because attachments "fail" with an error message (but still appear to be sent??)
2/ because upon sending the message "sending message" keeps "looping".

[JohnDoh]

Is there anything in the rc error log?

You should try with all plugins disabled and also check in your browser for any JS errors and finally a lot of browsers have some kind if debugger/inspector tool built in and you should be able to use that to check that AJAX responses from the server. If there was a JS error or the AJAX responses were not coming back right that could cause the behaviour you describe.

[t88462]

The error logfile did not show any entries since May.
After noticing some permission issue in another logfile, I fiddled around in the config and logs directories. Error logs are being written fine. I renamed some of the config files in the config dir and sure enough, errors are being logged.

This is a very odd issue. I've just installed a brand new roundcube 1.0.3, configured it via the installer, then changed the db_dsnw and connected to it.
Identical issue is going on.
Then I tried it with version 1.0.1 and even with 0.9.5, but still is the same behaviour. 0.9.5 complained about the DB structure having changed, obviously.

Think it is somehow still permissions related. If, like instructed, I change the temp & logs folders to be owned/writeable by the webserver (www-data), the installer check fails. Only if they are owned by php-fpm, does it work. All other files are owned by webserver. Tried changing that to php-fpm (and vice versa) without any luck.

Thanks for your suggestions. I'll see if AJAX is coming back & let you know. 

[t88462]

You should try with all plugins disabled

Think that is the default with new installations. Did not change things.

and also check in your browser for any JS errors

None mentioned specifically; neither in IE on Win 7, safari on OSX 10.10, FF on OSX 10.10, chrome on OSX, ... .

and finally a lot of browsers have some kind if debugger/inspector tool built in and you should be able to use that to check that AJAX responses from the server. If there was a JS error or the AJAX responses were not coming back right that could cause the behaviour you describe.

Hmm. Seems like a permission problem after all.

Error: Permission denied to access property 'href' app.min.js:79


Annnddd... a bit further I found this:
Load denied by X-Frame-Options: https://URL/roundcubedir/skins/larry/watermark.html does not permit framing.

I indeed added:
    add_header Strict-Transport-Security max-age=63072000;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
to my nginx config. Never gave it any second thought.

Of course disabling add_header X-Frame-Options DENY; resolved the issue.

Thanks for your support (and I apologise for wasting your time).