Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MarkerManager.setMarkerSvg fails if the cursor exists and has moved from the top level #8758

Open
1 task done
rachel-fenichel opened this issue Feb 3, 2025 · 0 comments
Labels
issue: bug Describes why the code or behaviour is wrong

Comments

@rachel-fenichel
Copy link
Collaborator

Check for duplicates

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

Description

MarkerManager.setMarkerSvg is implemented as:

  setMarkerSvg(markerSvg: SVGElement | null) {
    if (!markerSvg) {
      this.markerSvg = null;
      return;
    }

    if (this.workspace.getBlockCanvas()) {
      if (this.cursorSvg) {
        this.workspace
          .getBlockCanvas()!
          .insertBefore(markerSvg, this.cursorSvg);
      } else {
        this.workspace.getBlockCanvas()!.appendChild(markerSvg);
      }
    }
  }

If this.cursorSvg and the block canvas both exist, there's a call to blockCanvas.insertBefore(markerSvg, this.cursorSvg).

If the marker is created immediately after the cursor, this call works because the cursor SVG is a direct child of the block canvas. But if the cursor has been moved around or reparented (e.g. by calling MarkerSvg.setParent_, then the operation fails with:

Failed to execute 'insertBefore' on 'Node': 
    The node before which the new node is to be inserted is not a child of this node.

Reproduction steps

I found this by updating the keyboard-experimentation code to dynamically register and unregister the marker instead of creating it once and leaving it around (attempting to address google/blockly-keyboard-experimentation#181).

Stack trace

Screenshots

No response

Browsers

No response

@rachel-fenichel rachel-fenichel added issue: bug Describes why the code or behaviour is wrong issue: triage Issues awaiting triage by a Blockly team member labels Feb 3, 2025
@cpcallen cpcallen removed the issue: triage Issues awaiting triage by a Blockly team member label Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue: bug Describes why the code or behaviour is wrong
Projects
Status: No status
Development

No branches or pull requests

2 participants