8000 RangeError: Maximum call stack size exceeded when using FieldNumber or FieldTextInput due to recursive size_ setter · Issue #9055 · google/blockly · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

RangeError: Maximum call stack size exceeded when using FieldNumber or FieldTextInput due to recursive size_ setter #9055

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.

Sign up for GitHub

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

Jump to bottom
Closed
1 task done
mikeharv opened this issue May 15, 2025 · 2 comments
Closed
1 task done

RangeError: Maximum call stack size exceeded when using FieldNumber or FieldTextInput due to recursive size_ setter #9055

mikeharv opened this issue May 15, 2025 · 2 comments
Assignees
@cpcallen
Labels
issue: bug Describes why the code or behaviour is wrong

Comments

@mikeharv
Copy link
Contributor

Check for duplicates

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

Description

Starting in Blockly 12.0.0-beta.6, using built-in fields like FieldNumber or FieldTextInput can result in a RangeError: Maximum call stack size exceeded.

This is caused by the the introduction of an accessor in the FieldInput class (#9011). While the code looks correct, when compiled with common tools (e.g. Webpack/Babel), the call to super.size_ = ... is sometimes transpiled to this.size_ = ..., causing infinite recursion at runtime. This affects any project that uses FieldNumber, FieldTextInput, or other FieldInput subclasses.

This is a bundler-sensitive issue triggered by the recent introduction of an accessor for size_.

Reproduction steps

  1. Use 12.0.0-beta.6
  2. Add any block with a FieldNumber or FieldTextInput

Stack trace

ncaught RangeError: Maximum call stack size exceeded
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)
    at _class4.set (field_input.ts:109:5)

Screenshots

Image Image

Browsers

No response
@mikeharv mikeharv added issue: bug Describes why the code or behaviour is wrong issue: triage Issues awaiting triage by a Blockly team member labels May 15, 2025
@rachel-fenichel rachel-fenichel moved this to In Progress in Blockly Accessibility May 15, 2025
@mikeharv mikeharv mentioned this issue May 15, 2025
Closed
8 tasks
@mikeharv
Copy link
Contributor Author

Upon further investigation, this seems to be related to the @babel/plugin-transform-classes plugin where {"loose": true}. This configuration was causing the transpilation to ES5 which was changing super.size_ to this.size_. Since neither Blockly nor Code.org support IE 9/10 any more, we believe this is safe to change:
code-dot-org/code-dot-org#65894

Assuming I can put the above pull request through to our production environment without issues, I may be able to close this.

@maribethb maribethb removed the issue: triage Issues awaiting triage by a Blockly team member label May 16, 2025
@cpcallen
Copy link
Contributor

Closing this as it was caused by an issue in the developer's build toolchain rather than being a bug in Blockly itself.

@cpcallen cpcallen closed this as not planned Won't fix, can't repro, duplicate, stale May 16, 2025
@github-project-automation github-project-automation bot moved this from In Progress to Done in Blockly Accessibility May 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cpcallen cpcallen

Labels
issue: bug Describes why the code or behaviour is wrong
Projects
42B1 Blockly Accessibility
Status: Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cpcallen @maribethb @mikeharv
0