Insert Copied Cells" treats theme-styled empty cells as non empty

Posted by: averma on 24 August 2026, 4:26 am EST

  • Posted 24 August 2026, 4:26 am EST

    Product: SpreadJS (@mescius/spread-sheets v18.2.3)

    Environment: React/TS app, workbook-level theming applied via sheet.setDefaultStyle(style, GC.Spread.Sheets.SheetArea.viewport) — sets backColor/foreColor as the sheet’s default style (not per-cell explicit style).

    Steps to reproduce:

    Apply a custom defaultStyle (with backColor set) to a worksheet via setDefaultStyle(style, SheetArea.viewport).

    Enter a value in one cell (e.g. A1).

    Copy A1.

    Right-click an empty cell (e.g. C1, no explicit style, no value — only inheriting the sheet’s default backColor) → Insert Copied Cells → Shift Cells Right.

    Expected: Empty cells (no value, no explicit per-cell style) should be treated as empty for the insert/shift operation, regardless of the sheet’s defaultStyle background color.

    Actual: Cells that only inherit the theme’s default backColor (no explicit style, no data) are treated as non-empty by the insert-shift logic, producing incorrect shift/insert behavior.

    Question for support:

    Does the “Insert Copied Cells” emptiness check inspect the resolved/rendered style (including sheet-level defaultStyle) or only explicit per-cell style when deciding what counts as empty?

    Is there a supported way to apply a sheet-wide background color that is excluded from this emptiness check — e.g. a rendering-only property, vs baking backColor into defaultStyle?

    If this is expected behavior, what’s the recommended pattern for theming worksheet backgrounds without affecting insert/shift/emptiness logic elsewhere in the API (fill handle, sort, etc. — same category of issue we’ve hit before)?

    Why it matters: We theme every sheet via setDefaultStyle (whole-workbook theming system). This makes basic empty-cell semantics wrong app-wide for any operation that checks “is this cell empty.”

  • Posted 24 August 2026, 7:59 am EST

    Hi,

    Thank you for the information.

    We were able to replicate the behavior on our end. However, we are not yet sure whether this behavior is expected. We are therefore checking with our development team for further clarification.

    The internal tracking ID is SJS-35744.

    We will update you as soon as we receive any further information. If the behavior is not expected, we will also check with the development team to determine whether there is any workaround or alternative approach to achieve the desired behavior.

    Regards,

    Priyam

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels