Absolutely. All browsers, Firefox, Opera, Edge, I don't know what else my coworkers use.

It's driving the team insane. I can't figure out what the deal is with it.

I have heard this too, mostly Chrome based. I'm on 8339 currently (as of last 20mar24), but the problem was noted before that -  update 8825. Truth be told I thought it was user error, now I'm going to look more into this. 

Thanks for posting.

On my end few users reported simlar things. Something like cursor moves to the beggining of message after writing some first words but it was hard to replicate on my end.

Lack of replication is probably why it hasn't been resolved. As a programmer myself, it's vastly more difficult to debug without a straightforward way to replicate.  It looks like SM might be using an embedded Froala editor and there have definitely been reports over the years about jumping cursors and Froala builds that have addressed them.

In the meantime, I also confirmed with users that it happens when there is only one instance of the editor as well as when there are multiple instances open. A Froala github post led me to check on this aspect.

And, in December there was a Froala 4.1.4 version released that addressed jumping cursor within tables. Though, this doesn't quite apply since the jumps occur when composing text in general and not in editing tables.

+1 this is a long time bug... it is getting worse

This is most likely caused by an improperly formatted (or incorrectly placed) partial page update panel.

Something else on the screen is being updated and instead of only updating that one thing it is "hitting" the data entry form as well. "bumping" the cursor to the starting point of the data entry text area.

These issues are NOT that hard to troubleshoot, so ... yeah... not sure why it hasn't been addressed.

We are on an older version at my office (8451), and I don't recall any of our users reporting it as an issue.

In our most recent update, we have updated to Froala version 4.1.4. Despite our thorough investigation and the significant amount of time dedicated to enhancing the email compose feature, we've yet to encounter the issue you've reported. We suspect that interaction between certain plugins, such as Grammarly, and older client hardware may be contributing to the problem. Any assistance in replicating this would be greatly appreciated. 

Hi Marc.  This is an issue that we've seen with our customers and ourselves for a long time. But it is getting worse. In my case, I use Mac with Chrome, latest versions of OS and browser, a M1 MacBook Pro, NO plugins for the browser and I get it all the time.   

So older hardware is not the issue and plugins are not the issue, at least in my case. 

Thanks Mark. I will keep that in mind as we move forward.  Everyone is on Windows 10 and there may be a few plugins on those browsers. I have a really clean Win 11 build and I'm going to stick with only Edge on it, so perhaps I will hammer out some emails on it for a few days.  I appreciate how frustrating it can be to debug this and what a time sink it is.

If this is the same issue we are dealing with, I can tell you how to replicate it.

We are using Windows 10, FireFox and SmarterMail build 8797

We have seen a problem that if you have an email open and then change focus to another window, then come back to the email and click someplace edit it....  the composition box does not acknowledge where you newly clicked at (well, it does show the cursor there) but it instead starts editing the text at the last known cursor position before the window lost focus.

1) I create this :

This is a test of the lines

line 1
line 2
line 3
line 4
line 5

2) Place the cursor at the end of line 2

3) Change focus to any other open window

4) Change focus back to the composition box by placing the cursor at the end of Line 5 as if you were going to start typing.

5) you WILL see the cursor appear at the end of line 5 and flash

6) Press enter 2 times. When you start typing, instead of the composition box typing at the end of line 5 where you just placed the cursor, it will instead start typing at the end of line 2, where you had the cursor at before the window lost focus.

Curtis,

Thank you for the detailed steps. This is a step forward. We should be able to isolate the problem and fix.  I am a creating a development ticket for this now.

Curtis thank you so much for that. I am hopeful that an eventual fix to the reproducible bug you supplied also helps my original reporting.  Specifically "while in the process of typing, the cursor jumps to another line". In that case users are typing text, and then the cursor jumps and additional typing is inserted at the new cursor location. They are not switching to a different window, just simply going about their business of typing. It's not clear to me if users had changed cursor position (i.e. a last known cursor change) earlier in their typing session.

It is also ironic that when I went to reproduce your sample, as soon as I got to the end of typing "This is a test of the lines" and hit enter, the cursor disappeared completely and the new line was inserted _above_ where I typed "This is a test of the lines".  I am pretty sure I didn't click on another tab/window, but I could only reproduce it one more time out of about 10 attempts.

Eventually, I did find that the following is reproducible and it is a simplified derivation of your example:

I repeated this about 6 times and reproduce the bug in every try.

The most reproducible symptom for me occurs when replying.

- Reply to an email

- Change the recipient (either replace or add another recipient)

- Click in the editor window

- Type first line, hit enter

The first line drops one line and the cursor disappears. This is with the current Firefox on Windows 10, SmarterMail Build 8832 (Mar 7, 2024)

@secretwep

This may not be a SmarterMail issue.  We have been experiencing something similar just in Windows in general. What we are seeing is regardless of what window you are working in, some form of Windows Explorer refresh takes place that forces the active window to be whatever the most recent instance of Windows Explorer is that you have open.  Being a developer this drives me nuts... coding away, then all of a sudden my VS window is no longer the active window and instead my keystrokes are being interprted by whatever explorer window it transferred control to.  Fortunately I notice it on the screen right away.  But I HAVE managed to unknowingly delete a file due to this issue.   Have reported to Microsoft and no fixes as of yet.  When it happens seems totally random but I'm sure there is something in the Windows message queue that is triggering it.

Doesn't sound exactly like your issue, but could be related.  Just throwing it out there.

Try closing down any open Windows Explorer windows and see if your issue persists.

Rod, it is not a windows issue, I experience it in MacOS and many of our clients do too.

We are releasing a fix for this today.  Thank you for helping us replicate it.  We were able to replicate this and trace it down to a bug in the Froala editor and then implement a workaround.

The symptom I described above still exists in Firefox with 8860, but the cursor jumping that my coworkers were experiencing seems to be fixed.

Patrick, 

Is your organization accessing webmail using a published app server setup? Since javascipt engines on browsers use gpu for performance, serving an application through a remote app servers is notoriously slow. When replying to extremely large emails with a lot of table formatted html content, we have seen some lag but only in very rare cases (when the table data has malformed html).  

Marc,

I am using IIS on server 2019, nothing fancy. The machine is local here, and we have maybe a dozen active user accounts. The emails I reply to are generally pretty simple. I'll try to reproduce it on Mac OS at home, but I already know Opera and Edge don't do this.

Pat

Patrick,

Thanks for your feedback.  We have been able to replicate your issue with Firefox and a task has been sent to development.

I am the OP and this is not resolved.  Clients are still having issues where they are typing and the cursor jumps to previous lines while actively typing.  Additionally, the ability to highlight text and change the color or background is non-functional now. In essence, the editor is worse.

-John

I noticed yesterday I am unable to change the color of text.

Fixed: Replying to a message using Firefox may cause the cursor to jump after editing the first line.

Based on your feedback, we've identified the cause of the cursor jumping issues you've been experiencing. These problems originate from a bug in the Froala editor, for which we now have detailed replication steps. The issue began with our use of a flawed Froala method (selection.save) to resolve a problem where the "link file" tool was inserting the linked at the beginning of the message in our April 2023 release (8517). We are reverting the "link file" issue until we can get a fix from Froala. This will fix all jumping cursor issues and the other adverse affects like text color selection problems that arouse from our attempts to workaround the core issue.  

I really appreciate ST's attention and time put into this.

-John