Hmm, this is strange. Does this happen in all browsers? Or just a particular browser/device?

It’s happening in Chrome, Safari, IE and firefox

Hi Joe,

I found this bit of code in Salesforce’s ServiceDeskView.js file.

It basically says, if the active element is a “INPUT” or “TEXTAREA” element, don’t let the event do its default behavior. Since this listener is on the document element, I think it is interfering with CKEditor’s key processing.

So from my analysis, this is happening because of how code in CKEditor and the Salesforce Service Desk interact. I’ll take another look at this tomorrow and see if I can come up with a workaround.

Interesting. I am surprised it still fired the keydown event even though in the console settings, hotkeys are turned off. 

One approach I considered was to reinitializing the CKEditor TextArea on pageload. I’m not entirely sure howe ServiceDesk.js, Skuid, and CKEditor code would like that though.

Still looking for a workaround for this, but it might be more complicated that I first thought. I’m looking into whether we can attach the ckeditor events to an element inside of “window” so that its events fire before the servicedesk.js events.

Yeah the console view is tricky.

I’m pretty sure their code is to prevent the backspace key from doing anything when you’re not in a textarea or input element. This is most likely to prevent the unintentional “browser back button” behavior of the backspace key. The problem is that we use the “contenteditible” version of CKEditor, which uses just a normal div, not a textarea or input element.

Any luck or workarounds?

Hi Joe~

Unfortunately, this is a Salesforce bug that Skuid currently does not have a workaround for. We will let you know when we have addressed this in a future release.

Thanks!

Here is a link to this Salesforce known issue:

• Backspace button not working in text edition in latest version of Notes