TinyMCE Editor not loading properly under Chrome & Edge

segelfreak

Folks, does anyone also notice that the TinyMCE Editor often does not properly load when using either Chrome or Edge Browser? It doesn't happen when using Firefox, but that one is relatively slow with REI3 compared to Chrome based Browsers.
When opening eg a project, the editor will normally load and show the content. However, after editing and saving, then moving to another "mask", the editor will start to load (shifting 3 dots), but never finish.
I have to flush the cash of the browser and reload, after which it will work again, but only until the next editor load fails again. I'm on 3.10.5.5807 with a bare metal install (not docker). Chrome Version 136.0.7103.114, Edge Version 136.0.3240.76., Windows 10.
It's not always happening, but when it happens, it's really annoying.
Any ideas or similar experiences?

gabriel

I´ve had this issue pop-up in r3.10.2 and have looked over a fix for it in r3.10.5 that should have addressed this. And since then it did not appear for me anymore.

But if you are having this issue still in r3.10.5 there is probably an edge case we´ve overlooked.

Could you please tell me what you mean with "moving to another mask"? Are you talking about switching between tabs or are you going to another form and then the issue appears? It would help me replicate this issue, if you could go into more detail.

segelfreak

gabriel It happens when you have finished editing in a text window and switch to another data record, which should then load a text window again. If this was/is a known problem, I will dig deeper and see how it can be reproduced.

segelfreak

segelfreak It seems to appear really irregularly. Right after my above message, it happened again, when I clicked a task from a project gantt overview. the task popped open but the editor did not finish loading (thus showing the three animated points). I then cleared the chache and for more than 30 attempts to open other taks, it worked as intended.
wirth to mention that it did happen also from the list view, so it's not related to the gantt view.

gabriel

That would help, thank you for taking the time.
I will also have a look.

gabriel

It´s a really annoying bug. I´ve tried to replicate it a couple of times yesterday with no luck, but it happened to me today in our production system - unfortunately I am missing the tools to debug in production...

I´m on it, but still need to find the cause.

mobrien

Hi there - I've only been using the tool for a few months (Tasks / Projects / Tickets apps) and really like it. But I am seeing an issue which I presume is same as discussed above.

I use Edge browser...originally we used rei v3.10.3, but upgraded a few days ago to v3.10.5 after seeing this in the release notes:

Fixed: Richtext editor does not always load.

...However after upgrading, we're still seeing it (not sure if frequency has decreased).

The behavior we see is on Tasks, when updating Description or Notes fields, the editor doesn't load and we get the 3 dots / progress bar like this:

For me I was seeing it was pretty frequent (maybe 10-20% of the time I edited such fields). The solution / work-around I've found is to close the Task, navigate away (often to another Task or Project), and then come back...and then editor loads fine.

If this is a different issue, let me know, and I can take the discussion to a new thread.

Thanks!

gabriel

mobrien
No that´s pretty much the issue. I´ve worked on this myself and got another test version which I was hopeful for - but the issue appeared again today. Only once, but this means there is still a problem somewhere.

It´s a really annoying bug, as whenever I get to working on it, it does not appear.

segelfreak

gabriel It´s a really annoying bug, as whenever I get to working on it, it does not appear.

Indeed, this is also what I suffer from. Sometimes it seems I'm at it again, but then, after some minutes, the content appears. With huge delay, but still. (usually, the editor is very snappy and loads instantly without any noticeable delay).
Question is: is there something we can look at, when this happens? what info would you need to trace this back properly?
Since it is not easy to reproduce it under controlled conditions, it may be difficult to identify a "proper way" to cause this bug.

gabriel

segelfreak
Sorry, I cannot tell you what you can look at when this happens. There is no error, no warning.

I have reworked the richtext input component and the issue now appears much rarer - but I still encountered a case the other day, so I am not done yet.

segelfreak

Morning!
It appears to be very random, but today, I have had it again. So, what did I do? I opened up a new ticket, saved it and then added a number of work logs (Arbeitsprotokolle). 4 entries worked well, the 5th one, however, did not properly load the editor.
I saved each log entry and pressed the new button from within the saved log, so did not close the mask, but stayed within.
Which means that the bug occurs even within a single mask/task, just by repeating to save and hit new.

Looks like you can barely reproduce the bug, but have to "brute force" it?

Hope this info helps.

segelfreak

As we found out, the editor loads correctly after clearing the cache, it is likely that the browser is caching "outdated" or "faulty resources" (JS/CSS files of the editor).
Since I have this issue accessing the rei3 portal directly (by ip address; as well as via the nginx reverse proxy manager, I did not relate this to a possible prtoblem with the reverse proxy. But I wanted to look deeper into potential caching issues, The proxy could encourage this if it does not allow cache control headers to be passed on cleanly. I added the following to the proxy settings: (timeout was set before already)
proxy_send_timeout 12h; proxy_read_timeout 12h; proxy_hide_header Cache-Control; proxy_hide_header ETag; add_header Cache-Control no-store;

This makes the portal noticebly slower, but so far, I haven't been able to forcefully cause any loading issue.
I'll keep testing, but maybe that is something worth to investigate?

Edit:
Now added the following to the reverse proxy

location ~* \.(?:css|js|jpg|jpeg|gif|png|woff2?|eot|ttf|otf|svg)$ {
    expires 12h;
    add_header Cache-Control "public";
    access_log off;
}
etag on;
add_header Last-Modified $date_gmt;
add_header Cache-Control "must-revalidate, public";
# HTML 
location ~* \.html$ {
    add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate";
    add_header Pragma "no-cache";
    expires off;
}

# API-Routen 
location /api/ {
    add_header Cache-Control "no-store";
    add_header Pragma "no-cache";
}

The html part is probably unnecessary?

gabriel

Thank you for sharing your results. I am not entirely certain it´s cache related as there are no resource errors when the issue occurs. It seems like the editor is failing to attach itself to the DOM correctly due to a timing related issue - at least my tests point in that direction.

Resetting caches makes everything take longer to load, which could help indirectly avoiding the issue with the editor.

I am currently testing a version of the editor which uses a slight delay to wait for the entire DOM to settle before attaching itself. No errors so far, but I´ve been there before so I´ll test a bit longer before announcing success.

Regarding your proxy configuration: Honestly, no idea - I am not experienced with this proxy. 🙂

segelfreak

Thanks for this swift reply! I'm also not a specialist with proxies, but the charm with this is that I can overwrite the headers without changing anything on the host system.
As you say, any "delay" may coincidentally help. exciting...

segelfreak

Update: I can confirm the changes in proxy did not (!) solve the issue. Just popped up again.

gabriel

The error also popped up again once with the version I was testing - not fun. We´ve debugged quite a bit already, but still no idea why this happens. No errors, no hints, nothing.

We are currently testing a new approach to load and handle the editor. Though we are not thrilled about introducing a change like this in a patch release, it might be a good solution and even bring some benefits.

@all: If anyone is interested in testing this new approach, let me know and I´ll provide a download. This version would be update-safe and can be reverted if need be.

segelfreak

Happy to test it, of course!

gabriel

I really appreciate it 🙂

Here are the download links:

These are not the final versions of r3.10.7 but they are upgrade & downgrade safe.

segelfreak

Installed it (linux) and seems to run smoothly, as far as I can say after working just a bit. Feels even a bit more "snappy", but that's more of a gut feeling.
Will test over the coming days and update here, asap.

gabriel

segelfreak If you have not noticed much difference, we have apparently been doing a good enough job. 🙂

The old integration was via iframe, which is like another website being loaded into r3. The approach has some pros & cons, but worked reliably in the past. We reworked the component, to make it work via inline integration.

The new version should be a bit faster, as it does not need to load in another website for the editor - but even the old version was so fast that it never bothered us.

We have talked about making the change before, but it was not really a priority. Now after the change, I have not had the issue so far. Fingers crossed .)