Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS Firefox: "Unresponsive" keyboard when going back from next block using keyboard #9905

Closed
eiriarte opened this issue Sep 14, 2018 · 4 comments
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Type] Bug An existing feature does not function as intended

Comments

@eiriarte
Copy link
Contributor

When I move back to a previous block using the keyboard, the cursor goes back, but I can't type right away.

Steps to reproduce the behavior

  1. Posts → Add New
  2. Write title
  3. Write a first paragraph and press ENTER.
  4. You are now in the second paragraph. Go back to the first paragraph with LEFT CURSOR key (or BACKSPACE).
  5. You are now at the end of the first paragraph. Try to type something. Nothing happens. The cursor is there, but it is not responsive: you can only use keys like ENTER or CURSOR keys.

Notes

  • It also happens with headings and quotes, not just paragraphs.
  • It seems to work fine in Chrome.

Capture

ff_keyboard_bug

Versions: WordPress 4.9.8 / Gutenberg 3.8.0
System: macOS 10.11.6
Browser: Firefox 62.0 (64-bit)

@talldan
Copy link
Contributor

talldan commented Sep 14, 2018

Thanks for the report 👍 - I can also reproduce this consistently. No console errors or warnings. I also noticed another thing that may or may not be related in firefox. When backspacing into the previous paragraph block as mentioned above, superfluous <br> elements are created at the end of the paragraph.

edit: This superfluous br issue I mentioned seems quite hard to reproduce and probably unrelated, but I was seeing the data-mce-bogus br element being replaced by multiple normal br elements.

@talldan
Copy link
Contributor

talldan commented Sep 14, 2018

I've done some further debugging on this one and discovered that when functioning correctly the caret is properly placed at the end of the rich text. Calling this.editor.selection.getRng() returns that the selection range is correctly in the paragraph element's text node:

{
  startOffset: 4,
  endOffset: 4,
  startContainer: #text,
  endContainer: #text,
  // ...
}

When reproducing this bug, the range selected is completely different:

{
  startOffset: 0,
  endOffset: 0,
  startContainer: <br data-mce-bogus="1">,
  endContainer: <br data-mce-bogus="1">,
  // ...
}

So it looks as though we might be attempting to type within the br element.

I can't continue looking into this right now, but hopefully this information is useful.

@talldan talldan added [Type] Bug An existing feature does not function as intended [Component] TinyMCE [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels Sep 14, 2018
@ellatrix
Copy link
Member

@eiriarte I think #11287 fixes this issue as well.

@youknowriad
Copy link
Contributor

closed by #11287

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

4 participants