GrapesJS Issues

msftedad

Hi Team, Any update on this issue?

GJS Helper

This is a valid accessibility concern. The GrapesJS editor's canvas is rendered within an <iframe> element. For screen readers to properly identify and announce the purpose of this iframe, it needs an accessible name, typically provided by...

pierodetomi

I can confirm I’m seeing the same issue, and it’s caused by the disappearing element having a computed height of 0px (because it’s using display: none). While this is definitely a bug, as a temporary workaround you can avoid using display:...

GJS Helper

This is indeed a bug within the GrapesJS Layers panel's drag-and-drop functionality, specifically when attempting to move components that are semantically linked, such as an input element with an id and a label element with a for attribute...

lexoyo

Oh and i'd be happy to contribute if you tell me what solution i should focus on (a command to re-connect instances, an async method to load project data like what i do in silex, ...) cc @artf

artf

yeah looks like an issue with that way of loading pages 🤔 I don't see any issue on my side (full project load). What is the reason behind loading pages in that way?

lexoyo

yeah looks like an issue with that way of loading pages 🤔 I don't see any issue on my side (full project load). What is the reason behind loading pages in that way? It avoids blocking the main thread for too long. When users load a real l...

GJS Helper

The freezing issue you're encountering with your custom Dynamic List component in GrapesJS is a classic example of an event feedback loop. It occurs because the event listener responsible for updating the row count is too broad, causing it...

GJS Helper

Thank you for reporting this issue and providing a clear reproducible demo. The problem you're encountering with drag-and-drop in the Layer Manager after attempting to change its root is due to an incorrect usage of the layerManager.root c...

artf

Hey @msftedad the website repo is here, feel free to submit a PR with the fix (file/GrapesEditor.tsx)). I'm closing the issue as it's not related to the core.

GJS Helper

This is a valid and important accessibility bug report for the GrapesJS demo page. The issue stems from the <img> tag for the GrapesJS logo having an empty alt attribute, which incorrectly signals to screen readers that the image is purely...

artf

@jsxOverdose pushed a fix to this new release: https://github.com/GrapesJS/grapesjs/releases/tag/v0.22.11

jsxOverdose

@artf In the new version, there's another bug: when you click one of the resize handles on the Y-axis, it makes the image significantly larger. Here's the demo: https://jsfiddle.net/du81zL6r/

GJS Helper

The issue you're experiencing with elements jumping to an incorrect position after being moved and then interacting with the resizer is a known behavior related to how GrapesJS handles CSS top and left properties, particularly when positio...

mosh-tudor

@yashvi2026 That's because of your custom CSS code. Remove this part: from editor.BlockManager.add('image', {

artf

I confirm the component resizer doesn't account for !important right now, but I'd follow, more or less, what @mosh-tudor suggested. You don't need to remove the entire styles, as my guess is what you need, but I don't see the point of havi...

yashvi2026

I need to use !important in my style. I've noticed that in other components, when !important is included in the default styles, the styles added through the style manager also include !important to ensure they override the default. So, whe...

artf

Thanks for the report @jsxOverdose Will be fixed in the next release

GJS Helper

You've accurately identified a specific behavior in GrapesJS where inline styles appear to completely override ID-based CSS rules, even for non-conflicting properties. This is indeed a deviation from standard CSS specificity rules and can...

sumasal

temporary workaround for the impatient:

GJS Helper

It appears you've identified a bug in the GrapesJS dev branch where component dragging is still possible even when the editor is in preview mode. This is indeed contrary to the expected behavior, as preview mode should disable all editing...