BUG: Block Highlight Display Bug
See original GitHub issueVersion: 0.6.18
You can get the version by typing grapesjs.version
into the console
Are you able to reproduce the bug from the demo?
[ ] Yes [x] No
I think this may be due to the demo being in full screen mode?
What is the expected behavior? I would imagine that the Rich Text Editor toolbar placement should be near the text block being edited. Additionally, double-clicking the text object does not always trigger the RTE toolbar.
Describe the bug detailed This only appears to happen when the Editor is NOT in full screen mode. When it is on a standard browser window that can be scrolled, it seems that the placement of the RTE is or can be subject to miscalculation based on the window scroll position. Additionally, double-clicking a text block does not always display the RTE toolbar.
Update: Initially I thought it was just tied to the RTE placement. But it appears, as I mention in my latest comment, that it happens to content blocks when highlighting / selecting them IF the Grapes editor IS NOT in full screen mode and the top of the editor placement is not at the top of the viewport. I’ve attached a screencast in a zip file in my last comment in this thread.
Are you able to attach screenshots, screencasts or a live demo?
[x] Yes (attach) [ ] No

Issue Analytics
- State:
- Created 3 years ago
- Comments:20 (4 by maintainers)
@artf Like you, I wasn’t able to reproduce in a fiddle. So I began decomposing the HTML piece by piece until I discovered that one of the primary site containers had an
overflow-x: hidden;
defined on the class and for some reason or another that seemed to be playing havoc with the GrapesJS highlighting and toolbar placement. I corrected that issue and that, in addition to updating the latest version and assigning thelistenToEl
property, fixed everything. It really was theoverflow-x: hidden
on the rootdiv
that appeared to drive the issue.Thank you very much for your time and effort in helping me dig out this problem.
Look, in the latest release, we’ve added this option https://github.com/artf/grapesjs/blob/8822aa6c6e8ced09ad50f2c8392f1754d3a6ec8b/src/editor/config/config.js#L151-L157
So, at first, ensure you’re not serving a cached grapesjs version from your browser (run in devtools
console.log(grapesjs.version)
) and then check that your scrollable panel is the first parent of your<div id="gjs-container">
. In case, the scrollable panel is not the parent of your grapesjs container (which, by default, will be listened) you should be able to pass it as an option oflistenToEl