#6444: Balloon toolbar should reposition and ungroup items correctly when the window resizes #7795
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Suggested merge commit message (convention)
Fix: Balloon toolbar should reposition and ungroup items correctly when the window resizes. Closes #6444.
Additional information
This PR is another attempt at https://github.com/ckeditor/ckeditor5/pull/7721/files.
There are 2 things in this PR (this is hard but here we go):
A reverted
ResizeObserver
optimization (mentioned here https://github.com/ckeditor/ckeditor5/pull/7721#discussion_r461502549).Without it (or... actually with it), the
previousWidth !== entry.contentRect.width
in thisToolbarView
line https://github.com/ckeditor/ckeditor5/blob/i/6444-toolbar-reposition-on-regroup/packages/ckeditor5-ui/src/toolbar/toolbarview.js#L757 does not work.The
ToolbarView
optimizes the number of_updateGrouping()
calls so they only happen when:- it's the first resize in its lifetime (resize observer always hits when the toolbar first appears),
- the element width changes (but not, for instance, its height) (:point_left::point_left::point_left: this one matters),
- the update has been queued due to toolbar
maxWidth
change when the toolbar was invisible (editable resized when the toolbar was invisible)When the mentioned
ResizeObserver
optimization is in place, the "toolbar visible"->"toolbar invisible" state change is lost (the observer callback is not called then). SopreviousWidth
is actually a width before the toolbar disappeared. And when it re-appears, well... it's still the same, so the grouping is not updated.So this one actually fixes [Safari] Balloon editor toolbar should always expand when there's enough space #6444.
A new event fired by
ToolbarView
when it groups or ungroups its items (andBalloonToolbar
making use of it).When 1. is applied, the balloon toolbar does group/ungroup when it re-appears (GIF from [Safari] Balloon editor toolbar should always expand when there's enough space #6444). That's fine.
But a side-effect of this grouping/ungrouping is that it changes its width and being positioned absolutely (to its upper left corner) the balloon triangle starts pointing to nothing (or nonsense) 😕 (see the GIF below).
In other words: fixing 1. revealed 2.
So the
BalloonToolbar
plugin must listen to theToolbarView
event and re-position itself once the geometry of the toolbar has changed (due to grouping/ungrouping).Side note: At first I wanted to avoid the new event and make the
BalloonToolbar
use another resize observer (observing the toolbar element) and re-position based on this. But then I figured this may end in a race condition since- a toolbar internally uses a resize observer on itself to group/ungroup items,
- there's this resize observer observing the editable that sets toolbar's
maxWidth
If I added another resize observer, understanding which executed first and which last and whether the balloon repositioning happens before toolbar items grouping or after it would be a total mess. So an event is safer because it always happens after the internal toolbar's resize observer.