RunBox 7 webmail bugs that really annoy me

Speed: it’s so slow. Real lag in clicking any message before seeing it loaded in reading pane. Lag clicking on a new mail folder and see contents. Very slow loading of HTML mail contents after ticking show HTML.

Replying to email, takes several seconds to load up prior email as a quote, before I can start typing anything.

Many HTML emails received don’t display anything at all until I click to load HTML. Should be feasible to display some raw text stripped of HTML tags. Maybe an option to auto-load HTML from a whitelist or from emails in contacts list would help here.

Syncing speed: I regularly see a ‘sync n / 1234’ messages slowing ticking up.

Excessive browser CPU usage. With RunBox open in Firefox v76, CPU usage of Firefox jumps from 3% to 40-50%. I’m running an Intel i5-7300 2.6Ghz laptop with 16GB ram on Win 10, a web based mail client shouldn’t cause the fans on a laptop to crank up to max!

Deleting emails doesn’t update display. Open message, click delete. Message remains in mail list view and as a non-read message in count on folder list. Never properly updates display until I click another folder and then click back.

GUI oddites: with mail pane split vertically (list at top, message display below), when clicking the bottom most email visible in list, it triggers column sorting! Surely, only clicking a column header should trigger sorting and direction…

On mail viewing pane, too much vertical screen estate is taken up by toolbar, headers, a blank line below headers, another blank line with a html warning icon on right, then yet another line telling me HTML has been sanitised… I want to see my mail, not blank lines, redundant messages and padding!

At the moment I’m finding it barely useable, only good for emergencies when I’m not near a decent mail client application or my phone. Having come from WHM/CPanel installations with RoundCubeMail or SquirrelMail the user experience is deeply disappointing.

On the plus side, the UI looks clean and neat from a cosmetic point of view.

1 Like

I was about to post an inquiry about Runbox 7’s performance based on the experience with my two Android devices, but allow me to piggyback on your post.

Not sure if this is related to the service status updates mentioned here:
https://status.runbox.com/2020/04/23/access-issues-5/

The link above does state normal ops resumed 4/29.

In the last several weeks I’ve noticed a significant slowdown in RB7’s UI. My laptop’s ~10 years old, but I concur with your CPU numbers - jumps from 3-5% to 40-50% in Waterfox 2020.04 (based off FF 56), running on a Intel i5-m540 @ 2.53 GHz with 8 GB RAM. Thankfully RB6 is still lightweight.

I run FF 68 (latest ver) with NoScript on a Tab S4 and a Moto G5 Plus, both running Android 8.1 with 4 GB RAM. On the Tab S4, scrolling and updates are usable (though not snappy), while on the Moto G5 Plus, it’s unusable (scrolls barely budge the message list).

There’s also a bug I’ve seen on the G5 where if I scroll far enough down the message list in portrait orientation, the page display corrupts and I get a mini version of the list in the upper left corner of the page.

Wondering if this is related to CPU usage by the GUI as the G5 has the weaker CPU (Snapdragon 625 vs Tab S4’s Snap 835).

I can make peace with some of the other GUI issues you mentioned, but the laptop / desktop CPU usage is troubling, and the performance on Android FF is unacceptable. Chrome is only marginally better, and the RB6 site is desktop-only, so it’s back to email client apps until this improves.

Hey, @Arfa and @tempuser,

I feel for you guys and anyone who is using RB7, I myself stick to RB6 and only use RB7 beta in order to give feedback to the developers. Personally I don’t think they should have released RB7, it’s not ready for beta testing it’s more like alpha phase.

RB6 does mostly what I want. The one annoyance is that you can only download one attachments at a time, which actually is very annoying. Why they could not have issued a RB6 v1.1 with this issue addressed, I don’t understand? RB7 still has the same issue, which I think tells you a lot about the company maybe not getting it’s priorities right.

RB7 has some extras like diary and stuff, which is of no interest to me but if people really find it useful and it helps differentiate the RB7 product, then OK. But initially they should have concentrated on releasing a basic functioning web mail client that just worked! The indexing they could have possibly included in this although I have to say, so far I have seen no speed advantage when performing searches - the search menu is pretty underwhelming anyway.

Hello @Arfa and thanks for your comments.

Performance issues with Runbox 7 are likely related to the generic backend problems that we have been working on and that are now mostly under control.

When using a local/synchronized index, folder navigation and searching should be near-immediate when operations are running normally, and when using a relatively modern device on a decent network connection.

If you notice lag, we would appreciate it if you would be able to check the Web Console in your browser’s Developer Tools for errors, as well as the Network tab in said tools for any delays in the communication with the server. Details from these can help us pinpoint where the specific issue lies.

Your experience could also be related to this issue which is under investigation:

Since indexing and synchronization is happening on the local device to achieve this functionality, changes in CPU load may occur on each index update (every 15 seconds) and this seems more noticeable on Windows systems depending on index size. We will look into this discrepancy further.

When accessing message content the front-end is using the same back-end as Runbox 6, but may be more sensitive to slowness on the servers and we are investigating this issue as well.

We are increasingly focusing on streamlining the UX to remove remaining points with performance issues. We have for instance made improvements to functionality such as marking (multiple) messages in the list, and are working on further improvements to make all functionality respond immediately.

Regarding HTML messages they are always sanitized for security reasons, a text version of the message should be shown if HTML view is not enabled (whether or not one was included with the email, which should be the case).

A related issue which may overlap with what you describe can be found here:

Regarding overall layout and vertical spacing, we have this existing issue:

I should emphasize that the majority of our users are very happy with Runbox 7, and that we are adding further resources to resolve remaining obstacles such as those described here.

– Geir

@Geir
On the plus side of your comments I can see now that issues with the backend are affecting front end performance - not a surprise to me - and I guess this will all take time as you optimize the backend to work with RB7. But how do you know that a majority of your users are happy with RB7? Sorry this is not a facetious question. Dave has confirmed to me that only a fraction of your users are active on RB community site. So how are your getting feed back from the remaining users? Regards @johntowler

For transparency @JohnTowler had asked about this privately and I said that “most of our customers don’t use the forum website” and this is easily evident from the number of people who contribute here. This is normal for community websites.

We receive comments in support tickets and also via the project on GitHub. We also have some statistics on how much use Runbox 7 gets. The majority of the comments are positive but of course people do also point out bugs at the same time along with improvements and suggestions for features that they would like to see.

Some more info for you. Just loading up RunBox 7 today, to browse emails, this is the constant churn in the console:
Done persisting to indexeddb main.00db2efefc3e941ebda1.js:1:149398
Getting latest messages from server after
Date Tue May 26 2020 14:32:02 GMT+0100 (British Summer Time)
main.00db2efefc3e941ebda1.js:1:149398
Adding to index 10 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 9 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 8 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 7 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 6 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 5 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 4 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 3 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 2 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 1 to go main.00db2efefc3e941ebda1.js:1:149398
All messages added main.00db2efefc3e941ebda1.js:1:149398
us false main.00db2efefc3e941ebda1.js:1:149398
(folder:“Inbox” OR folder:“INBOX” ) main.00db2efefc3e941ebda1.js:1:149398
Persisting to indexeddb main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/indexLastUpdateTime main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/docdata.glass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/iamglass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/postlist.glass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/termlist.glass main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/indexLastUpdateTime 1402 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/docdata.glass 1453 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/iamglass 1453 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/postlist.glass 2002 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/termlist.glass 1712 main.00db2efefc3e941ebda1.js:1:149398
Done persisting to indexeddb main.00db2efefc3e941ebda1.js:1:149398
Getting latest messages from server after
Date Tue May 26 2020 14:32:02 GMT+0100 (British Summer Time)
main.00db2efefc3e941ebda1.js:1:149398
Adding to index 10 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 9 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 8 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 7 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 6 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 5 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 4 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 3 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 2 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 1 to go main.00db2efefc3e941ebda1.js:1:149398
All messages added main.00db2efefc3e941ebda1.js:1:149398
us false main.00db2efefc3e941ebda1.js:1:149398
(folder:“Inbox” OR folder:“INBOX” ) main.00db2efefc3e941ebda1.js:1:149398
Persisting to indexeddb main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/indexLastUpdateTime main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/docdata.glass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/iamglass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/postlist.glass main.00db2efefc3e941ebda1.js:1:149398
store remote entry /rmmsearchservice966128/xapianglasswr/termlist.glass main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/indexLastUpdateTime 994 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/docdata.glass 1069 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/iamglass 1056 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/postlist.glass 1520 main.00db2efefc3e941ebda1.js:1:149398
stored remote entry /rmmsearchservice966128/xapianglasswr/termlist.glass 1499 main.00db2efefc3e941ebda1.js:1:149398
Done persisting to indexeddb main.00db2efefc3e941ebda1.js:1:149398
Getting latest messages from server after
Date Tue May 26 2020 14:32:02 GMT+0100 (British Summer Time)
main.00db2efefc3e941ebda1.js:1:149398
Adding to index 10 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 9 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 8 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 7 to go main.00db2efefc3e941ebda1.js:1:149398
checking for updates main.00db2efefc3e941ebda1.js:1:149398
Adding to index 6 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 5 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 4 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 3 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 2 to go main.00db2efefc3e941ebda1.js:1:149398
Adding to index 1 to go main.00db2efefc3e941ebda1.js:1:149398
All messages added main.00db2efefc3e941ebda1.js:1:149398
us false main.00db2efefc3e941ebda1.js:1:149398
(folder:“Inbox” OR folder:“INBOX” ) main.00db2efefc3e941ebda1.js:1:149398

With each round of “Persisting to indexeddb” to adding to all 10 indices, taking just over 18 seconds.
It just seems to be constantly busy, churning over, using up a fair chunk of CPU for little perceiveable gain. Whilst all the time having a sluggish UX as you try to load and render emails or long waits for UI updates to show message as marked red or deleted from a folder.

@Arfa Thanks for the log. It appears the app is downloading the same indexed messages repeatedly, which is not normal.

There appears to be discrepancies in your account’s index on the server and we have initiated a re-index which should help. This could be caused by server issues that have since been resolved, or that certain messages caused errors in the indexing process.

Please stop and restart index synchronization in a few minutes. Note that this will trigger a re-download of the entire account index, but thereafter it should be kept in sync.

– Geir