Home key handling

1

Has the home key default browser behavior? I didn’t find any keymap.

In my list home jumps to the end of previous list item:

  • first item
  • second | item

press home

  • first item |
  • second item

In the example editor home works in list item as expected.

2

Yes.

Which browser does this happen in? I’m not seeing it in Chrome and Firefox.

3

Very strange. I tested the same text without pm just contenteditable and home works as expected on list item. Let me narrow down the problem.

4

In your example editor content of list items are inside a paragraph:

<li><p>first item</p></li>
<li><p>second item</p></li>

For my use case list items accepts only inline content as the paragraph influences the wysiwyg experience:

<li>first item</li>
<li>second item</li>

It looks like this causes the wrong cursor position for the home action. How can this happen if home should have the default browser behavior?

By the way the end key works as expected.

5

It seems to be a firefox problem. In chrome and edge home works as expected, I’m currently using firefox quantum 58.0.1.

6

I tracked down which event causes the strange jump:

view.dom.addEventListener(“focus”, () => this.poller.start(hasFocusAndSelection(this.view)))

Once I comment out this line home key works as expected.

7

That listens for DOM selection changes so that ProseMirror can keep its selection state in sync with the DOM selection.

8

There is another event added by poller.start (selectionchange) which causes a transaction. I tracked down this further and found once this.docView.update(state.doc, outerDeco, innerDeco, this) is executed home starts to fail.

But now I get lost, where is the code for this update function?

9

That’s in viewdesc.js, but it’s likely that the problem is in the selection update, not the document update (which that line handles).

10

You are right the problem occurs in selectionToDom at this line.

In chrome, which works well, it returns at this line but firefox does not. The content of lastSelection differs:

chrome

firefox

Now I know where it happens but still don’t know the cause of it. I might give up…

11

I still can’t reproduce this in Firefox 58 when I set list items to contain inline*. Can you set up a self-contained demo that shows the issue, for example by editing https://glitch.com/edit/#!/remix/prosemirror-demo-basic ?

12

Thank you very much for your patience! I did find the cause. Pressing “home” returns wrong result for native command getSelection(). Instead of the text node it gets back the li node. This happens for:

  1. firefox quantum (linux and windows tested)
  2. ‘li’ without ‘p’
  3. use of //cdn.rawgit.com/milligram/milligram/master/dist/milligram.min.css"!

I was not aware that css influences this behavior and I have no idea how this can.

To see the effect have a look at this simple jsfiddle code. Jumping can not be seen here (no pm code). Please test key ‘home’ for the first item it will return UL instead of #text.

For second item text is inside ‘p’ and key ‘home’ returns #text as it should. Key ‘end’ return for both items #text node.

13

You could try submitting a Gecko bug (or see if it has already been reported), since that definitely seems like a bug (home/end selection motion should happen within the current text block—moving to the list node when pressing home in an list item is just weird).

14

Yes, that’s for sure a ff bug, will submit a report if not done yet. Finally it’s just this small css stuff which took me hours of debugging:

ul { list-style-position: inside; }

Edit: I opened this bug report in bugzilla