Macros at The Beginning Or End Of Document (or List Entry)

Sometimes it seems to be difficult to move the editor’s text cursor in front of or behind a macro “block” if this block is positioned directly at the end or the beginning of the document / edited area, or sometimes also if it’s e.g. the last element in a list entry.

Would it somehow be possible to always provide a “virtual” location for the text cursor to be positioned to next to a macro block, so adding content in front of / behing a macro block becomes easier?

Or is there another trick I’m missing?

The “best” workaround I found so far is to write the text on the “wrong side” of the macro block, and then reposition / move the macroblock using the mouse afterwards. However, this is neither obvious for many users, nor does it work in all circumstances, sometimes requiring to switch to source code view to enter the text where I want it to be - which may not be an option for non-tech-savy users.

There is a red magic line that should appear when you hover a block at the start or end of the document. Please provide the exact steps to reproduce. Maybe there is an edge case where the magic line doesn’t appear.

I get the magic line for instance when I edit the Sandbox home page, scroll to the end where the table of contents macro is and hover the macro block right at the end (bottom). I’m talking about Magic Line | .

Mh, my confusion may stem from the following (really strange / obscure) behaviour - I’m using Xwiki 12.10.5 with In-Place-Editor, Chromium Version 89.0.4389.82 (just in case this makes a difference):

  1. Enter edit mode.
  2. Enter some Text, e.g. “this is a test”
  3. Add a macro in the same line, e.g. my "mention"ing a user.
  4. Position the cursor somewhere in the “this is a test” text in front of the macro.
  5. Press the “End” button.


The cursor jumps to the end of the line, behind the macro.

What actually happens:

The cursor disappears and the keyboard focus is lost. Pressing the “left” or “right” cursor buttons does not change anything.
Pressing “End” again moves the editor to the end of the document.

Additional info:

  1. The same happens with the macro directly at the beginning of a line or list item and text behind it, if you then press “Pos 1”/“Home”.
  2. This behaviour does not occur if the macro is not the first or last editable element in the line.
  3. Very interesting (to me, at least): This behaviour with the “End” button can NOT be reproduced any more if text was added behind the macro at the end of the line, which is then deleted again afterwards, such that the macro ends up being the last (or first, in the alternative example) element in the line again. In this case, “Home”/“End” buttons actually work as expected.

I could not find any Jira issue which seemed to describe this - is it a known behaviour? I consider it to be very confusing… Shall I report it as a bug?

The caret position and keyboard navigation in general is controlled by the standard CKEditor and the browser. There are a few open issues related to this on their side, specifically when widgets (what we use to display macros) are involved. See for instance:

The behavior is not always consistent between browsers and the caret can sometimes get hidden within the read-only area of a widget (protected macro output). There’s not much we (XWiki) can do about this.

Ok,thanks for the feedback!

I struggled a bit to find out which version of CK Editor Xwiki actually ships / embeds - before I continue searching, maybe you can point me in the right direction?

I wanted to cross-check if the observed behaviour can be reproduced with the CK Editor demo and if so, if it’s already reported at their github repository.

Indeed not easy since we don’t have a binary dep on CKEditor (and thus you cannot ask XWiki’s Extension Manager for the dependency…) but we build it from sources (at application-ckeditor/pom.xml at master · xwiki-contrib/application-ckeditor · GitHub)…

Mh, ok. I reported a new issue against CKEditor (Keyboard Cursor/Editing Focus Lost When Pressing Pos 1 and First Element Is Widget · Issue #4593 · ckeditor/ckeditor4 · GitHub) which I also observe in Xwiki.

However I could not reproduce the “cursor is ‘swallowed’ when a widget is the last element in a line and I press ‘End’” in the CKEditor demos - basically the opposite of my report. It’s reliably reproducible in Xwiki, though…

Chromium Version 89.0.4389.82

Thanks, so it’s CKEditor 4.16.0.

Yes, my issue just got confirmed on GitHub.

At least that’s the first step for getting it fixed… :slight_smile:

As I could not reproduce the “cursor is ‘swallowed’ when a widget is the last element in a line and I press ‘End’” in the CKEditor demos, might that be an Xwiki editor specific bug, or didn’t I try hard enough?

I would have to investigate to tell you more. You can report an issue on the CKEditor Integration side for now . My guess is that it’s related to #16942 (Cursor gets stuck in inline widget) – CKEditor .