BUG: Block Highlight Display Bug

[HeyWrecker]

Version: 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

[MartinPutz]

@HeyWrecker I've seen something similar when no device is selected or the canvas is manipulated by external JS. Could you check the currently selected device using:

https://grapesjs.com/docs/api/editor.html#getdevice

editor.getDevice();

[HeyWrecker]

@MartinPutz Thanks for the reply. I threw that function in a console.log and it returned an empty string. No value at all. Not sure why- the editor is initializing and is otherwise fully usable. Thoughts?

[MartinPutz]

@HeyWrecker You could try selecting a device after you initialize the editor.

const editor = grapesjs.init({
 ...
});
editor.setDevice('tablet');

Assuming you have that device added to the editor(before selecting it) for example:

const deviceManager = editor.DeviceManager;
deviceManager.add('tablet', '900px');

https://grapesjs.com/docs/api/device_manager.html#devicemanager

[HeyWrecker]

@MartinPutz

Is there a string preferred for desktop browsers? This is not running on a tablet. Or is the tablet value just a catch-all and the width is the more important value?

[MartinPutz]

@HeyWrecker That was just an example. These are custom devices, you can call them whatever you want, and you can have pretty much as many as you want.

deviceManager.add('tablet', '900px');
deviceManager.add('tablet2', '900px', {
 height: '300px',
 // At first, GrapesJS tries to localize the name by device id.
 // In case is not found, the `name` property is used (or `id` if name is missing)
 name: 'Tablet 2',
 widthMedia: '810px', // the width that will be used for the CSS media
});

So the same way you can setup a desktop one and a mobile one too. Or even if you really want you can add certain devices just like the developer console, for example you could add Iphone11, Samsung Galaxy Note 10 etc.

See documentation for more info: https://grapesjs.com/docs/api/device_manager.html#add

[HeyWrecker]

@MartinPutz I've been looking at the API page for the Device Manager and I'm still not sure of it's relation to the editor. Is this what determines which "Device" is active initially if you have the responsive icons (Desktop, Tablet , Mobile)?

Either way, it doesn't seem to help with the placement. I set the device to desktop and it still shows the RTE floating in odd places sometimes.

I had better luck swapping it out with the CKEditor plugin. That seemed to consistently anchor itself on the block that was actively being edited.

Thank you very much for your time and assistance, however. It is appreciated!

[HeyWrecker]

Hmmm. I take it back. It's not just the RTE. It's the layout in general. Even just selecting an element when the page is scrolled incorrectly displays the highlighted segment outline and toolbar. This doesn't appear to happen in full screen mode, only when the editor is in part of a scrollable page.

[HeyWrecker]

I've created a screen capture to illustrate the block highlighting behavior when the editor is included as part of a page. It's zipped because .mov isn't an allowed upload file type. But, as you'll see if you watch the clip, when I start out at the top of the page the block highlights are significantly off from their placement in the editor. As I scroll down the page gradually you'll see that the begin to line up until finally, when the editor is at the "top" of the current scrolled view, the blue highlights line up exactly with where the block elements are placed in the editor.

grapesjs_block_highlighting_behavior.mov.zip

[HeyWrecker]

Additional screenshots:

Default Page Load, mousing over the main content area:

Scrolled so that editor is at top of viewport:

[HeyWrecker]

This seems like it might be similar or related to issue https://github.com/artf/grapesjs/issues/495

[artf]

@HeyWrecker Can you try with the latest version, please? (seems to be related to #2722)

[HeyWrecker]

@artf I will give it a try and report back. Thanks!

[HeyWrecker]

This is with v0.16.22 of GrapesJS. I am also using the grapesjs-mjml plugin at version 0.1.15. Could that have something to do with it?

[HeyWrecker]

I upgraded both GrapesJS and GrapesJS MJML plugin to their most recent versions and it appears to continue. I'm attaching a zip of the screencast as the animated gif version didn't cover enough of it.

grapesjs_highlight_bug.mov.zip

[artf]

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 of listenToEl

[HeyWrecker]

Thank you @artf , I can confirm that I am running a non-cached version of 0.16.22. The editor is not inside a modal or scrollable panel. This is just a standard browser window as illustrated in the video. The page has other elements above the GrapesJS editor that causes the page itself to be scrollable so the editor is never full above fold of the page. If I either put the editor into full screen mode or I line the page up so that the editor is at the top of the viewport, the misalignment does not occur. It occurs when I scroll the page as I'm using the editor.

I did try setting the listenToEl property to [document.getElementsByTagName('body')[0]] to ensure that it was listening to the body element. It did not seem to make a difference.

[artf]

Unfortunately, I'm unable to reproduce on my side, can you create an online reproducible demo please (eg. via JSFiddle)?

[HeyWrecker]

Sorry, @artf , I was off on Friday. I'll try to reproduce in a fiddle as requested.

[HeyWrecker]

@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 the listenToEl property, fixed everything. It really was the overflow-x: hidden on the root div that appeared to drive the issue.

Thank you very much for your time and effort in helping me dig out this problem.

[artf]

Great, thanks for the update Rick