Repository navigation
Inline toolbar gets recreated on every action used #2822
Description
Might not be a bug, but a feature.
Whenever you click on any of the available actions inside inline toolbar (i.e. make text bold, italic, underlined, etc) the whole inline toolbar gets recreated. It's smooth and invisible it you don't use any transitions or animations on this toolbar. But if you open the inline toolbar with a bit more ✨fashion✨, then you get some flashing every time you use any of the inline tools.
Steps to reproduce:
- Add some transitions to .ce-popover__container (to clearly see the problem)
- Type some text
- Open inline toolbar by selecting some parts of the text
- Use any of the inline tools, for example, make that text bold
- See the flashing
Expected behavior:
- The whole toolbar doesn't get recreated but instead the state of each button is updated using classes or data attributes?
- This will allow us to have entry and leave transitions and animations for the inline toolbar
Video of the bug:
https://github.com/user-attachments/assets/ff6be587-b52a-45f8-a8bb-ac3399a35221
OS: Window 11
Browser: Google Chrome 128.0.6613.114
Editor.js version: 2.30.5
Activity
obafemitayor commentedon Jan 3, 2025
@neSpecc @idebenone Can I take a look at this if no one is working on it?
idebenone commentedon Feb 7, 2025
Yes you can!
Sawtone commentedon Sep 17, 2026
Hi @neSpecc @idebenone~
I reproduced this on v2.31.7 and have a local prototype that prevents flickering by keeping the inline popover container mounted while refreshing its contents. However, tool instances and buttons are still recreated, preserving their existing cleanup and rendering behavior.
Visually, it behaves as expected in my reproduction: formatting actions no longer cause flickering or replay the container’s entry animation.
Chromium checks pass for formatting states, link cleanup, shortcuts, positioning when switching blocks, and closing the toolbar while rendering is pending. Firefox and Safari validation is still pending.
Would you be open to a focused PR with this scope, or would you prefer a broader, more comprehensive fix? I’d appreciate your thoughts.
neSpecc commentedon Sep 17, 2026
@Sawtone, feel free to open a PR. We’ll review it. It would be better if tools weren’t recreated, but as I understand it, there’s a logic bound on the selectionchange that leads to it.
Sawtone commentedon Sep 18, 2026
@neSpecc I’ve prepared a focused fix #3027, the relevant information is put in it.
I also confirmed a separate existing issue on both versions: opening Link focuses its input and clears Italic’s active indicator, although the text remains italic; closing Link restores the indicator. I’ve left it outside this patch and would be happy to open a separate issue and work on a fix.