Usually in the text editors, and also, let’s say, in Google docs, when you press the Delete key in the end of a paragraph, it moves the next paragraph to the current one, joining the two paragraphs.
This doesn’t happen in ProseMirror, at least not by default. The example on https://prosemirror.net/ doesn’t behave like this.
Is this intentional? How could the joining behavior be achieved?
Thanks!
It does, for me. Which browser and platform are you testing with?
I see the problem on Ubuntu 24 with:
But I don’t see it with the latest Firefox on Ubuntu. That is, Delete key moves the next paragraph to where I am located (ie. works like I would expect).
Also, I see the same strange behavior on TipTap examples that I can find.
So, I guess reproducing this issue should be easy? I can do more tests if needed. Even debug it.
This works as expected on Chrome (Linux) for me. Do these browsers have any extensions active? Do you have an uncommon keyboard layout?
I do have a Finnish layout, but I just installed a fresh Ubuntu 24 in a qemu virt-manager and used an English (US) layout. With Chromium 131.0.6778.85, still the same problem. With Firefox, no problem.
On Windows, with Chromium 131.0.6778.139 it seemed to work ok.
Is this 131.0.6778.85 somehow broken then…
I was testing 130 before. Upgrading also gives me 131.0.6778.139, which works. Possibly Chrome had a short-term regression? Can you upgrade to .139 on that Ubuntu vm and see if it makes a difference?
Yes, but for some reason the snap and apt are lagging behind:
snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all Internet users to experience the web.
commands:
- chromium.chromedriver
- chromium
services:
chromium.daemon: simple, disabled, inactive
snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking: latest/stable
refresh-date: today at 13:38 EET
channels:
latest/stable: 131.0.6778.85 2024-11-28 (3002) 184MB -
latest/candidate: 131.0.6778.85 2024-11-28 (3002) 184MB -
latest/beta: 130.0.6723.44 2024-10-14 (2973) 181MB -
latest/edge: 133.0.6847.2 2024-11-28 (3005) 185MB -
installed: 131.0.6778.85 (3002) 184MB -
Ok, I installed the latest edge 133.0.6847.2, but still see the same problem.
I guess there is still something somewhere. But what and where…
Tried in Brave 1.73.101 Chromium: 131.0.6778.139 (Official Build) (arm64) (MacOS, obviously), with Brave Shields enabled. Works as expected, so at least it doesn’t seem to be the Shields.
My Kubuntu installation has 131.0.6778.139 and it works as expected (English layout.)
I found the reason.
By putting a breakpoint in prosemirror-view / editHandlers.keydown(), I could see that the Del key that I’m pressing is interpreted as:
event: {
code: "NumpadDecimal",
key: "\u0000",
keyCode: 46
}
The same Del key works fine in the same browser’s textareas, but not in TipTap/ProseMirror editor.
But, when I put a keydown handler into a textarea, the event is similar. So this key won’t send key: "Delete" for some reason.
And, the Del key that I’m pressing is in the Numpad and is a double function , or Delete.
If I put NumLock on, I get this:
event: {
code: "NumpadDecimal",
key: ",",
keyCode: 108
}
Using the other Delete key on the keyboard the editor works as expected. Never have used that though.
In Firefox I get key: 'Delete' as expected.
Would it make sense to start using keyCode for delete? Or maybe I should report this to Chrome team.
If your num lock is such that this key should be acting as delete, and the browser is reporting it as NumpadDecimal, that does sound like a browser but (especially if Firefox doesn’t behave that way). I think reporting it to the Chrome team is the way to go.
I did report it. Chromium
But I may not be the only one with this problem and the fix may take a while.