rte toolbar bug

[alimajed93]

Hello all,

I am using the latest grapesjs stable version (40) and I noticed the following bug in the rich text editor: If the user drags and drop a rich text editor into the canvas, clicks on it and tries to clone it per example (or any action in the toolbar like delete, ...), no action will happen. The user has to select another block per example, or just click outside the text editor, then clicks again on the text editor, to be able to perform the toolbar actions.

Any idea what could be causing this issue? I started noticing it after moving to the new version, I was before using v17.

Thank you for your help.

[artf]

Yeah, that happens because of this check, being in editing mode we need to prevent some actions (eg. clicking canc/backspace triggers the same command). Probably we need to put some kind of force option

[alimajed93]

Hi @artf ,

Oh I see.
Can you please give me some examples of why we added this check? I mean what problems were we having and were solved by this check?

Thanks.

[artf]

Without those checks, for instance, in text editing mode CTRL+C/V instead of just copying/pasting the selected text will copy/paste the component. This is why I suggest a kind of force option

[arthuralmeidap]

Hi @artf ,

I have been thinking about this problem.
What do you think about adding a validation, when a shortcut is pressed like ctrl+c, to run only when the editor is not on editing mode or the canvas has not the input focused?
It would be to change this line https://github.com/artf/grapesjs/blob/dev/src/keymaps/index.js#L148 and add this validation.
Any thoughts on this?

[arthuralmeidap]

@artf , Just to make myself clear about the last comment.

The fix would be move this validation here https://github.com/artf/grapesjs/blob/dev/src/commands/view/ComponentDelete.js#L5

from the command classes and move to the https://github.com/artf/grapesjs/blob/dev/src/keymaps/index.js#L148.

That would make less duplicate code, and will fix the problem.

It would deactivate the key bindings when the editor is on editing mode.

Can you see any problems on this approach?

[artf]

@arthuralmeidap actually you're right, all current default keymaps should work like this (be off when something is editing, like text component or input element).

Can you see any problems on this approach?

The only possible caveats I see in this approach is what to do when someone wants to trigger a keymap even in editing mode. For this case, I'd suggest adding a new options argument in Keymaps.add method, eg:

add(id, keys, handler, opts = {}) {
	...
		if (ableToRun || opts.force) {
			typeof handler == 'object' ? handler.run(editor) : handler(editor);
			...
		}
	...
}

[arthuralmeidap]

PR: #1800

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.