[BUG] Highlight and toolbar positioned wrong on outside scroll

[tomaskallup]

Are you using the latest release (older versions are NOT supported)? Yes Are you facing the bug with your local copy of GrapesJS or with the current demo? Local

• OS: Archlinux
• Browser: Firefox 74.0 and Firefox developer edition 75.0b11
• Grapes: v0.16.3

What is the expected behavior?

• Highlight should update its position when the outside scrolls

What happens instead?

I did my best to try and replicate this behaviour, but couldn't. Even using the same stack (parcel, typescript, react, ant design) it seemed to work. So I would like some insight as to how I can debug this.

Looking at the events in inspector, the scroll event is there. In my replication attempt (https://github.com/tomaskallup/grapesjs-react-scroll-issues) about the same styles should be applied (there is a flexbox which has scrolling content), but the issue isn't present there. (UPDATE Repo has been updated, issue is now present there, see https://github.com/artf/grapesjs/issues/2722#issuecomment-617154850) If I switch the editor to fullscreen, it works perfectly.

[artf]

Yeah really weird, my first guess was that canvas toolbars weren't updating on the window scroll, so I've tried to create a non-fullscreen example with a long page but I've realized that there is no scroll listener (on the main window) because is not necessary, toolbars are positioned correctly without that listener. So, the only reasonable problems I can think about might be the Firefox browser (so try to see your page in Chrome, please) or maybe you're loading your page inside an iframe because that might be an issue, in that case, you would need to set up a scroll listener and propagate it to the editor

[tomaskallup]

Hi, thanks for the reply!

Firefox doesn't seem to be the issue here (same behaviour in Chrome) Also the replication repo works in both browsers without the bug.

I'm not loading anything in iframe (this is inspector layout from the actual page) Only custom styles applied to the upper elements are some margins, paddings, min-height and max-width. Looking at it, the content seems pretty much same as in the replication repository, so I'm just getting more and more confused.

One thing I noticed, it "fixes" itself when resizing window (untill you scroll again)

[tomaskallup]

@artf I think I found the cause, our root element <div id="❤"> has this style:

#❤ {
    height: 100vh;
    display: flex;
}

Adding that to the reproduction repo caused the issue to appear! (Removing the flex seems to fix the issue, I'll investigate if we really need it in our case, but atleast now there's actual reproduction)

[tomaskallup]

Alright, after even more investigation, it breaks even without the flex, because we still want to make the body not scroll, as the <section class="ant-layout"> has to be the one scrolling (due to the sidebar). A fix that comes to mind is a config option to select an element to which grapes would then bind the scroll listener, how does that sound?

[artf]

Yeah probably adding an option like listenToScroll (as an array, to allow multiple elements) would be a good thing. As your case is quite common, I think it might also be useful adding the parent of the editor container element to the option (if is empty)

[mumumilk]

I also managed to reproduce this bug in stackblitz if anyone wants to see it:

https://stackblitz.com/edit/js-3myvqp?file=index.js

Add any element and scroll down a little bit to see this behaviour:

i also noticed that if i remove the overflow: auto it prevents this bug from happening.

There is any known workaround for this?

[artf]

It should be fixed in the next release

[siddhi1397]

Hi @artf , One scenario where there are multiple containers of editor, then this misalignment is coming up after giving unique id to every editor container. Can you please help me if I am missing something out? I have provided outer scroll body class to listenToEl and it's working when it's single editor.