The autocompletion panel should prefer the south positon #4643

Reinmar · 2019-04-04T08:47:32Z

Instead, it prefers the north position:

Reinmar · 2019-04-04T08:48:52Z

cc @dkonopka @oleq For me it was intuitive that the panel should display below the text. So does happen e.g. here on GH. But in some apps, where it sticks to the editing field and not the caret (e.g. Slack), it's displayed above. I consider this a different case, but wanted to verify it with you.

oleq · 2019-04-04T09:24:06Z

The positioning algorithm has the limiter defined as editable element.

It chooses one of the available positions which fits the panel within the editable rectangle the most. If none of the positions fits perfectly into the editable, the one with the greatest intersection area is chosen. Hence the "north" position.

We can remove the custom limiter restriction so then the positions are

matched against the greatest intersection area with the viewport
considered in the order of preference

@jodator Why the limiter in the first place, BTW? Does it have a specific role, or fixes a specific case?

jodator · 2019-04-04T11:36:58Z

I was struggling with consistent behavior of the positioning algorithm and during some test it turned out to be working well. Later the problem (stick to the firstly chosen position) was solved by reading the panelView.position IIRC. The limiter make sense also to position the mention panel with the consideration of the editing area.

jodator · 2019-04-04T11:55:08Z

considered in the order of preference

I'd remove the limiter and probably this should sort out the problem.

jodator · 2019-04-10T11:35:28Z

I was debugging why the balloon is choosing the north position where there's clearly a place to the south of cursor?

Because it does better fit in the default limiter (document.body):

So using the default limiter (document.body) should play along with features that shrinks the document body (looking at you ckeditor5 inspector) but will produce "wrong" results for short content.

@oleq Are we OK with this? Using the default limiter (document.body) on manual test would probably need some fixes in manual tests.

oleq · 2019-04-19T09:39:52Z

So using the default limiter (document.body) should play along with features that shrinks the document body (looking at you ckeditor5 inspector) but will produce "wrong" results for short content.

Well... a short body (shorter than the viewport) and the editor being the last child (or so) and inserting around at the bottom of the editable does sound like an edge case to me. Developers can easily fix that by expanding <body> using CSS (html, body{ min-height:100%; }). Besides, there's no harm in displaying to the top in that case. The feature remains 100% useful.

As for the inspector and other floating elements that could clash with the panel, AFAIR there's no API that would help us resolve this issue out–of–the–box. We would need to exclude those elements from the area available for the panel to position itself and, in fact, we have an issue for that.

Other: The mention UI panel should prefer positions below the caret rather than above it for a more natural UX. Closes #37.

Reinmar · 2019-05-28T14:32:43Z

Did ckeditor/ckeditor5-mention#52 actually change anything? I don't see any change in the behaviour.

jodator · 2019-05-28T14:39:18Z

It's done inline with this comment: ckeditor/ckeditor5-mention#52 (comment) & ckeditor/ckeditor5-mention#52 (comment).
The mention UI prefers south position and is constrained within editing area. So the issue as such was considered invalid.

Reinmar · 2019-05-28T14:41:34Z

Please show me on screenshots what has changed because I can't figure that out myself. I mean – a case in which the panel will show up in a different position than previously.

jodator · 2019-05-28T15:05:01Z

It depends on the editor size, the body size and the position of the content.

The logic behind it doesn't changed as of the comments I've posted - we are not forcing the south position in every case - ie when the editor body is short because we prefer to constrain the UI withing editor (editing area) then overlaping content.

So most interesting static cases (first open):

Big editor, mention inside text (prefer south)

Narrow editor - height of editing area < mention ui height (prefer south)

Big editor - end of content (prefer editing area)

Now the dynamic behavior (first open, then typing):

Big editor, mention inside text (prefer south - stays south

)
Narrow editor (starts south - stays south)
Big editor - end of content (starts north

stays north)

Similar as 3 but starts with smaller UI (mention ui fits south) - starts south - stays south

This is for manual tests. For documention pages the behavior might be slightly different due to different sizes of the editor and pages AFAICS. So the calculations of "best" area might be dependent on the content around the editor (I've added some text in the body so the issue from that comment wouldn't affect screencasts.

Reinmar · 2019-05-29T07:20:12Z

Interesting – I couldn't get the same results in the documentation. This panel chooses the north position unless there's space in the editor below the caret.

Actually... it looks broken. Why does it pick the north here:

When it picks the south here (when there's still not enough space):

It doesn't seem to work reliably.

jodator · 2019-05-29T09:08:34Z

Well I'd argue that it does ;)

The docs have different CSS styles and the rendered line is bigger. I've added logging to the getBestPosition() which calculates which position from a set is the best given the criteria. For mentions we provide limiter - in this case an editing area (as other features) and the ContextualPanel (or Balloon I don't remember which now) sets the fitInViewport to true. So the best position is that which fits most in the viewport and in the editing area.

Now for the same content look how it calculates the best position:

On the screenshot above I've logged each step of internal positions.each() call (I've also logged the return condition but is always falsy as it not fully displayed in the limiter).

As you can see positions are evaluated: caret_se > caret_sw > caret_ne > caret_nw (hence the "prefer south" is valid here).

Now for each position the algorithm checks how mention UI will be contained in VP viewport & LIM limiter area - editing area.

In the docs the editor have different line heights and it turns out that caret_ne is slightly better contained in the limiter area then caret_se by 316 square pixels (~3.6%) which is marginal but is bigger.

Reinmar · 2019-05-29T09:49:54Z

Hm... I think I realized what caused my confusion – I thought that we consider only the editable area for the limiter. But it seems that the toolbar is also considered as a part of the preferred area... which is a bit counterintuitive for me.

The other thing which I didn't get is that we compare areas and choose the biggest one. I thought that it works differently – try to use the first position, if not acceptable (doesn't fit), check the next one. What's important is that in the screenshots I posted above the panel doesn't fit in the limiter regardless of its placement. I'd expect that if it doesn't fit, we prefer S. But sometimes it chooses S and sometimes N because, as you explained, we compare only areas.

The current solution behaves kinda like an unstable sorting algorithm. Sometimes you'll get this, sometimes that. If you don't know the algorithm, you don't understand as a user why you got something else than a second before for nearly the same initial situation.

jodator · 2019-05-29T10:06:30Z

Hm... I think I realized what caused my confusion – I thought that we consider only the editable area for the limiter. But it seems that the toolbar is also considered as a part of the preferred area... which is a bit counterintuitive for me.

No. We consider the editing area - not whole editor with toolbar: https://github.com/ckeditor/ckeditor5-mention/blob/711ebbac96d05153b175d4d47964903ba4c536a6/src/mentionui.js#L530-L540

The editing area in the docs is bigger then in manual tests:

The other thing which I didn't get is that we compare areas and choose the biggest one. I thought that it works differently – try to use the first position,

The algorithm works this way only if the whole panel is contained withing limiter. In here it does not so we evaluate all positions to find the best - see the "is fully displayed: false" in the logs.

On your screens shots you have editors of different height (3 lines vs 4 lines). So on the second one it chooses south as it is better contained within editing area the other positions (namely north). On the first one it chooses north because of slightly (3.63% as calculated above) bigger area of fit in editing area.

jodator self-assigned this Apr 4, 2019

oleq closed this as completed in ckeditor/ckeditor5-mention#52 Apr 24, 2019

oleq referenced this issue in ckeditor/ckeditor5-mention Apr 24, 2019

Merge pull request #52 from ckeditor/t/37

63cd822

Other: The mention UI panel should prefer positions below the caret rather than above it for a more natural UX. Closes #37.

mlewand transferred this issue from ckeditor/ckeditor5-mention Oct 9, 2019

mlewand added this to the iteration 24 milestone Oct 9, 2019

mlewand added status:confirmed type:bug This issue reports a buggy (incorrect) behavior. package:mention labels Oct 9, 2019

jodator mentioned this issue Oct 11, 2019

T/37: The mention UI should prefer position below the caret. ckeditor/ckeditor5-mention#52

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The autocompletion panel should prefer the south positon #4643

The autocompletion panel should prefer the south positon #4643

Reinmar commented Apr 4, 2019

Reinmar commented Apr 4, 2019

oleq commented Apr 4, 2019 •

edited

Loading

jodator commented Apr 4, 2019

jodator commented Apr 4, 2019

jodator commented Apr 10, 2019

oleq commented Apr 19, 2019 •

edited

Loading

Reinmar commented May 28, 2019

jodator commented May 28, 2019

Reinmar commented May 28, 2019 •

edited

Loading

jodator commented May 28, 2019

Reinmar commented May 29, 2019

jodator commented May 29, 2019 •

edited

Loading

Reinmar commented May 29, 2019

jodator commented May 29, 2019 •

edited

Loading

The autocompletion panel should prefer the south positon #4643

The autocompletion panel should prefer the south positon #4643

Comments

Reinmar commented Apr 4, 2019

Reinmar commented Apr 4, 2019

oleq commented Apr 4, 2019 • edited Loading

jodator commented Apr 4, 2019

jodator commented Apr 4, 2019

jodator commented Apr 10, 2019

oleq commented Apr 19, 2019 • edited Loading

Reinmar commented May 28, 2019

jodator commented May 28, 2019

Reinmar commented May 28, 2019 • edited Loading

jodator commented May 28, 2019

Reinmar commented May 29, 2019

jodator commented May 29, 2019 • edited Loading

Reinmar commented May 29, 2019

jodator commented May 29, 2019 • edited Loading

oleq commented Apr 4, 2019 •

edited

Loading

oleq commented Apr 19, 2019 •

edited

Loading

Reinmar commented May 28, 2019 •

edited

Loading

jodator commented May 29, 2019 •

edited

Loading

jodator commented May 29, 2019 •

edited

Loading