Thomas Bruederli wrote:
Sjon wrote:
After loosing an important mail composed under Roundcube (just pushed the send-button, 'something' went wrong and the email was lost forever) I have thought of ideas to avoid this. I think the following might be feasible: currently mails are send in the background; a failure means the message disappears. Might it be an idea not to use an AJAX backgrounded thread for sending the email, but staying on the foreground; only to return to the inbox once the message has succesfully been send?
Usually, RoundCube shows the compose page with all submitted form data again, if sending failed. Don't know what went wrong in your case... but you're right, sending the message in the background (mails are currently sent in the "foreground") would be a better solution.
I think we agree that an email should never be lost if sending it failse; I don't know what the exact solution should be for that.
Some other stuff I thought of:
- move the current overflow-scrollbar style from the table to the tbody. This would leave the thead always visible, while currently it will disappear when scrolling
If somebody can provide CSS code that works in all common browsers (yes, including IE) we will not hesitate to implement it. I already spent hours on this but did not succeed.... I recently found this but did not try it out because it's a real hack: http://groups.google.ch/group/Web-Development-Room/browse_thread/thread/70c7...
A colleague of mine was saying it was rather easy; so I'll ask him for some good example code :)
- make the attachment-icon (singleclick) in the messagelisting jump directly to the message-attachment. Currently it is just an icon without any link
And what should happen, if there are more than one attachments?
Interesting point. How about jumping to the #attachment in the message?
- could we merge the _auth (GET) and sessid (COOKIE) into 1 sessionID?
The _auth hash is an additional security feature. It contains the session-id (from cookie) as well as the client IP and these are checked on request. To steal someones session you have to fetch to cookie, the hash and fake your hosts IP.
Then what is the real use? :) I think almost all web applications are secured with a single sessionID which (I think) has always found to be secure enough. What is the actual security-addition here? I think we should drop it :) If we would like to check for IP-changes store the IP-address in the _SESSION to check for (even thought IP-changes are sometimes valid)