Incorrect cursor position on hitting backspace on keyboard at the end of line

[amitUpscale]

trafficstars

Expected behavior.

Type a statement in editor. Go between two words which has a space and add an extra space. Now go to the end of line and hit backspace. Editor should remove the last character of the line.

Actual behavior.

Instead of removing the last letter of the line, the cursor goes back to added extra space between two words in the statement

Editor version.

4.0.13

OS.

MacOsBigSur

Browser.

Chrome is up to date Version 103.0.5060.114 (Official Build) (arm64)

Recording.

https://user-images.githubusercontent.com/79836070/179208081-ff7767f2-f08b-4cf9-9fca-7cb7545c0695.mov

[ConnorsFan]

On Windows 10, I see the same problem in Chrome and in Edge, but not in Firefox.

[ghost]

Any update here. I know this will be a small bug for you guys to fix.

[rogerfar]

This is major showstopper for us.

[burtonrhodes]

Hopefully this can be fixed soon. Having many complaints with my user base on this one. Thanks!

[rogerfar]

They said it will be fixed in the next release somewhere at the end of August.

For now I rolled back to the previous version.

[ConnorsFan]

This appears to be a duplicate of issue 4463.

[bpautsch]

Please fix ASAP. I have many customers complaining about this. Thanks!

[richardkmichael]

@rogerfar Where did they say that? I'd like to follow-up with Froala Support, because this is affecting our users.

[richardkmichael]

Here is the most basic reproducer, in Froala 4.0.13:

Type 1<space>, then move the cursor to the start (to the left of 1) and type 2<space>, then move the cursor to the end (following the 2<space>, and type 3<delete>. The cursor erroneously jumps to the right of 2<space> and deletes the <space> following the 2 instead of deleting the 3.

This occurs in Chrome (latest) Version 104.0.5112.79 (Official Build) (arm64).

It does not occur in Firefox (latest) 103.0.2.

Occurs on both Windows and macOS.

Also, is this related to #4495 ?

[rogerfar]

Hi Roger,

We are aware of this issue and the fix will be available in the next editor release which is expected to be released by the first week of August.

I appreciate your patience

[bpautsch]

Hi Roger, We are aware of this issue and the fix will be available in the next editor release which is expected to be released by the first week of August. I appreciate your patience

This needs to be released ASAP. A hotfix would be fine. We've been receiving a ton of complaints and promised a fix to our customer by August 10th per the above message from Froala.

[natikgadzhi]

We've reached out to the support over email a couple weeks back, and @ilyaskarim told us the fix should be in 4.0.14, with the same timeline as @rogerfar has.

I hope the release will be out soon — I've just seen Ilyas mention 4.0.15 in another issue (#4493), so one would assume 4.0.14 is ready-ish?

[richardkmichael]

Support has told me a release (presumably 4.0.14), fixing this issue, is coming this week.

[natikgadzhi]

@ilyaskarim, hey! Delays happen, we all are working on software projects and we feel for you. Still, 4.0.14 seems to be delayed for a few weeks.

Is there a beta release channel on npm we can use to see if what you currently have solves the problem? Could you maybe scope this release down, and release 4.0.14 with just the patch for backspace behavior, and push everything else to 4.0.15? What's the holdup?

Or, is there maybe an opportunity for licensed customers to contribute back? If we can request and get the source code — is there a spot/ channel / chat where your customers teams could talk and try and figure out a solution on their own while you're still busy preparing the release?

[ilyaskarim]

@ilyaskarim, hey! Delays happen, we all are working on software projects and we feel for you. Still, 4.0.14 seems to be >delayed for a few weeks. Is there a beta release channel on npm we can use to see if what you currently have solves the problem? Could you maybe >scope this release down, and release 4.0.14 with just the patch for backspace behavior, and push everything else to 4.0.15? >What's the holdup? Or, is there maybe an opportunity for licensed customers to contribute back? If we can request and get the source code — is >there a spot/ channel / chat where your customers teams could talk and try and figure out a solution on their own while >you're still busy preparing the release?

We encourage our customers to contact us through the support channel as the most effective form of support https://froala.com/contact. We have released V4.0.14 that fixes the issue and you could test the behavior on this jsfiddle demo: https://jsfiddle.net/ilyasfroaal/b1dpyj5f/3/.

[natikgadzhi]

This is not resolved.

[natikgadzhi]

https://www.loom.com/share/8e729add420f463da393b2a78b032366

[markedmondson]

@ilyaskarim

This still exists in 4.0.14, the line in question is:

if(g.opts.enter!==V.ENTER_BR&&n&&n.previousSibling&&n.previousSibling.previousSibling&&"BR"===n.previousSibling.previousSibling.tagName&&n.previousSibling.previousSibling.remove()

This was introduced in 4.0.9, seemingly to fix "Removing a sentence after a BR tag, does not remove the BR tag". It's tough to replicate the issue mentioned in the changelog without knowing the full origin but that line is way more damaging than what it seemingly aimed to solve.

Note: This is a different issue to #4463