Skip to content

Deserializing from JSON still calls XML serialization #9253

Description

@maribethb

Check for duplicates

  • I have searched for similar issues before opening a new one.

Description

XML serialization requires certain DOM APIs, because it calls document.createElementNS. However, today, many environments exist for running JS that don't have a document object. We use jsdom to make this work in node, but there are still environments where using jsdom is not desired or feasible.

Using JSON serialization instead should be a reasonable substitute for devs operating in environments without the DOM. However, doing so still calls into the XML system, and I don't think this should be necessary. The chain is Blockly.serialization.blocks.append -> new Blockly.Events.BlockCreate (not directly as events are registrable) -> Blockly.Xml.blockToDomWithXY

The BlockCreate event serializes the created block into both json and xml. But the run method for the event only ever uses the json property, so the xml is created but never used. I think this was done for backwards compatibility reasons, where event listeners might use the xml.

Removing this would be a breaking change, but wouldn't affect most people unless they have event listeners that use the xml. Those could be updated to use json or if your events really depend on the xml being present, then you can register a replacement class for BlockCreate that does it. So I think this should be possible to remove in a major release.

As a workaround, if you are using headless workspaces in an environment without dom, try calling Blockly.Events.disable before you deserialize json into the workspace.

See this forum post for a motivating example.

Reproduction steps

Stack trace

Screenshots

No response

Browsers

No response

Activity

  1. added
    status: triageIssues awaiting triage by a Blockly team member
    breaking changeUsed to mark a PR or issue that changes our public APIs.
    and removed
    status: triageIssues awaiting triage by a Blockly team member
    on Jul 24, 2025
  2. self-assigned this
    on Dec 19, 2025
  3. added theissue type on Jul 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

breaking changeUsed to mark a PR or issue that changes our public APIs.

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions