The Cannot read properties of undefined (reading 'renderers') error occurs on loading sandbox
🐛 bug report
Preflight Checklist
- [ x ] I have read the Contributing Guidelines for this project.
- [ x ] I agree to follow the Code of Conduct that this project adheres to.
- [ x ] I have searched the issue tracker for an issue that matches the one I want to file, without success.
Description of the problem
Some examples with devextreme / devextreme-angular packages fail to load with the following error:
Cannot read properties of undefined (reading 'renderers')
Stack:
VM45:8 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'renderers')
at Gi.getRendererIndex (eval at W (preview-protocol.js:2:61), <anonymous>:8:58136)
at Gi.getFibers (eval at W (preview-protocol.js:2:61), <anonymous>:8:58454)
at Gi.hasSourceInfo (eval at W (preview-protocol.js:2:61), <anonymous>:8:58605)
at Object.enabled (eval at W (preview-protocol.js:2:61), <anonymous>:8:61806)
at cp (eval at W (preview-protocol.js:2:61), <anonymous>:8:62428)
at c.handleCodeInjection (preview-protocol.js:2:921)
at s (preview-protocol.js:2:504)
Also the following errors may appear
[BABEL] Note: The code generator has deoptimised the styling of /node_modules/@angular/core/fesm2022/core.mjs as it exceeds the max of 500KB.
(anonymous) @ babel.7.21.8.min.js:1
t @ babel.7.21.8.min.js:1
Hm @ babel.7.21.8.min.js:1
ZG @ babel.7.21.8.min.js:14
(anonymous) @ babel.7.21.8.min.js:14
l @ babel.7.21.8.min.js:1
(anonymous) @ babel.7.21.8.min.js:1
(anonymous) @ babel.7.21.8.min.js:1
l @ babel.7.21.8.min.js:1
D @ babel.7.21.8.min.js:1
(anonymous) @ babel.7.21.8.min.js:1
(anonymous) @ babel.7.21.8.min.js:1
MB @ babel.7.21.8.min.js:7
sync @ babel.7.21.8.min.js:7
stopHiding - secret - don't use this - v1 @ babel.7.21.8.min.js:7
oV @ babel.7.21.8.min.js:14
Kve @ babel.7.21.8.min.js:14
(anonymous) @ babel-worker.ts:518
n @ asyncToGenerator.js:3
a @ asyncToGenerator.js:22
(anonymous) @ asyncToGenerator.js:27
(anonymous) @ asyncToGenerator.js:19
Qe @ babel-worker.ts:501
(anonymous) @ babel-worker.ts:798
n @ asyncToGenerator.js:3
a @ asyncToGenerator.js:22
Promise.then
n @ asyncToGenerator.js:12
a @ asyncToGenerator.js:22
(anonymous) @ asyncToGenerator.js:27
(anonymous) @ asyncToGenerator.js:19
(anonymous) @ babel-worker.ts:789
(anonymous) @ child-handler.ts:97
n @ asyncToGenerator.js:3
a @ asyncToGenerator.js:22
(anonymous) @ asyncToGenerator.js:27
(anonymous) @ asyncToGenerator.js:19
handleCallRequest @ child-handler.ts:89
(anonymous) @ child-handler.ts:64
n @ asyncToGenerator.js:3
a @ asyncToGenerator.js:22
(anonymous) @ asyncToGenerator.js:27
(anonymous) @ asyncToGenerator.js:19
handleMessage @ child-handler.ts:44
(anonymous) @ child-handler.ts:28
Additional information:
The issue doesn't occur for all users. Some are not affected for unknown reason The issue can be fixed if you "fork" an example again
How has this issue affected you? What are you trying to accomplish?
We're sharing CSB sandboxes samples to our clients on demand
To Reproduce
Run a sample to see that Preview never displayed on the first load and the error occurs
Link to sandbox: link
Your Environment
| Software | Name/Version |
|---|---|
| Сodesandbox | n/a |
| Browser | Chrome Version 138.0.7204.93 (Official Build) (arm64) |
| Operating System | Mac OS Sequoia 15.5 |
@CompuIves would be great if you are able to confirm if there are known issues around this. I've also started seeing this, and issues with sandpack not loading in the last few hours. Weirdly it seems to coincide with an update to chrome 138 (same as mentioned in the above report), and since then everything is falling over - but same site is working on firefox 🤷
Trying to work out if it's an issue on my side, but since (some) sandboxes are also failing I'm not sure.
Taking a look! I have a hunch on what the issue can be.
Merging a fix now
@CompuIves thank you so much, lifesaver! Confirming all looks good now! 😅
[edit: sometimes still needing to empty cache and hard reload, seems sporadic - sometimes it works, sometimes fails, but working more than it was a few hours ago... same for codesandbox and even saw some aww snap for https://sandpack.codesandbox.io/ after leaving it in a tab for a while ... will check again tomorrow after some time passed]
@CompuIves still seeing this happening with sandpack 🤔
If I hard reload, it works for a short time, but then this happens again (usually says 'starting' for too long, then app displays a full blank page .. something causes an eventual re-render and i see the error above. SO weird. Is there any link with this report or just coincidence on the blank page?
Very interesting. I will take a look in a moment! Do you have a link to a page with Sandpack that is failing?
@CompuIves It's very hit and miss, but still failing quite a bit if you poke around different examples here using the menu on the left. This is a test deployment which i'll leave up, since ~~I'm going to try to temporarily disable~~ have disabled live preview on the live site for chrome 138+.
@CompuIves Thx a ton! CSB sanboxes work much more stable for us now.
We found just a few examples that still don't work. Here is one of them: https://codesandbox.io/p/sandbox/simple-array-forked-hxytj6
hook.js:608 EntryNotFound: File does not exist
at NP.create (https://codesandbox.io/p/assets/vendor-ee51c33d.js:696:9585)
at yc (https://codesandbox.io/p/assets/vendor-ee51c33d.js:696:9692)
at https://codesandbox.io/p/assets/vendor-ee51c33d.js:961:38353
simple-array-forked-hxytj6:1 Access to image at 'extension-file://codesandbox.codesandbox/media/activitybar-icon.svg' from origin 'https://codesandbox.io' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: chrome, chrome-extension, chrome-untrusted, data, http, https, isolated-app.
activitybar-icon.svg:1
Failed to load resource: net::ERR_FAILED
webWorkerExtensionHo…e-1633eaef.html:122 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'sha256-OTnWt0xD0mDGlMgzQref1DqApnE9MipgFz2t0Q/3vcE=' https:". Either the 'unsafe-inline' keyword, a hash ('sha256-nUrg/LC2AvKxy8MiCKkgkoCjbRJ+/y56dcrIPqdtj9A='), or a nonce ('nonce-...') is required to enable inline execution.
index.js:101 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://hxytj6.csb.app') does not match the recipient window's origin ('https://codesandbox.io').
content.js:1 Uncaught (in promise) The message port closed before a response was received.
errors.js:6 Uncaught Error: unsupported
Error: unsupported
at Module.De (extension.ts:421:18)
at monaco.ts:618:15
at o (run-with-latest-value.ts:32:22)
at go (run-with-latest-value.ts:36:5)
at we (with-monaco-config.ts:15:3)
at Tp (monaco.ts:617:3)
at Module.De (extension.ts:421:18)
at monaco.ts:618:15
at o (run-with-latest-value.ts:32:22)
at go (run-with-latest-value.ts:36:5)
at we (with-monaco-config.ts:15:3)
at Tp (monaco.ts:617:3)
@artem-kurchenko interesting that this ☝️ seems to load ok in firefox too, though there are still console errors (but not chrome 138).
@stevelewis99 Right now it displays a blank screen for me in FF as well
Firefox 140.0.4 , Windows OS 11
@artem-kurchenko how strange!
Displaying for me with Firefox Version 140.0.4 (64-bit), MacOS 15.5 (24F74)
Could this be related at all? https://github.com/getsentry/sentry-javascript/issues/16743
@CompuIves still seeing this happening with sandpack 🤔
If I hard reload, it works for a short time, but then this happens again (usually says 'starting' for too long, then app displays a full blank page .. something causes an eventual re-render and i see the error above. SO weird. Is there any link with [this report](https://issues.chromium.org/issues/429585228) or just coincidence on the blank page?
@CompuIves sorry for the noise, just shooting in the dark a bit trying to find a solution. However if you are still investigating, I have some more data points that might (or might not) help
Using another laptop I was able to test my site using chrome 136 and it works perfectly fine, but i could reproduce the issue using Brave (which was using Chromium 138)
However in my site, I have options for using different templates that are based on react, angular or vue .. and I think it's only the react one which is causing this issue on chrome(ium) 138, since the angular and vue options are working fine.
The code I'm using in sandpack for the react flavor that fails, is using the react-ts template which seems to use the create-react-app environment from codesandbox, at least what I'm guessing from the screenshot I pasted earlier ☝️
Could there be something about this template which is not liked by the latest version of chromium? I can't think of any other ideas ... 🤷
Yes, very weird. I can repro this occasionally. I'm looking at it again, but Chrome is not helping out that much (no relevant errors). I worry it's related to an update to Chrome. I'm investigating further!
Opening https://hxytj6.csb.app/ as a standalone URL shows it in some way. At some point, while loading the resources, the browser suddenly completely hangs. Network calls don't resolve and opening sources in devtools time out. As if something in Chrome completely got stuck because of something. It's hard to debug because the Chrome becomes unresponsive to the devtools.
Huh now I tried again with the same URL and it works! This is triiicky
I also cannot repro this with Safari, so I think this is indeed a Chrome 138 thing
@stevelewis99 Right now it displays a blank screen for me in FF as well
Firefox 140.0.4 , Windows OS 11
I think this error in particular was still based on the other fix I did (cannot read renderers from undefined). That should be fixed now, but might have taken a bit because of our caching to go live.
Opening https://hxytj6.csb.app/ as a standalone URL shows it in some way. At some point, while loading the resources, the browser suddenly completely hangs. Network calls don't resolve and opening sources in devtools time out. As if something in Chrome completely got stuck because of something. It's hard to debug because the Chrome becomes unresponsive to the devtools.
Yup totally agree - there are no console errors or other clues to go on. It's annoying.
What is weird though, is that everything is still there in the DOM when i get the blank page (clarify: in my app, not the link you shared) - you just can't see it. if you use 'inspect element' and hover around, it shows the elements of the page are still there.
That's just a side effect though, doesn't help establish a cause.
The only other thing I found is that there is no content in the response for GET https://2-19-8-sandpack.codesandbox.io/babel-transpiler.dc3397b1.worker.js when it fails vs when it's successful, but again could be an effect not a cause
I know it could be because the response never came back, but the headers look the same when (status 0) when a response is received and everything works. Could that be a thing? Now I'm getting out of my depth of knowledge though!
Huh now I tried again with the same URL and it works! This is triiicky
yup - it's a nightmare. inconsistent. thanks chrome!
I tried to open an issue using the chromium bug tracker in Chrome & Dia, but I'm getting an error back. I will add a response to the existing issue.
I've responded to this issue tracker just now: https://issues.chromium.org/issues/429585228.
@CompuIves thank you! Hard to find any info about changes in 138, except for a CVE that was fixed but no details shared yet. Maybe it's related 🤷 Was the fix to just 'stop doing everything'? 😂
The only other insight i just found, is that for me whether it fails or works correlates with the content (or complexity of the content?) rendered in the sandbox. Not the lines of code, but the resulting components. e.g. a simple chart is working ok, but a full dashboard of them is causing that failure we're seeing. edit: it's inconsistent, actually - sometimes simple chart fails that worked a minute ago, but more complex seems to give higher chance of failing 🤔
Connecting dots that may not be related .. but wondering if some protection mechanism is now kicking in as part of the fix for potential exploits, but only when there is heavier memory usage or whatever triggers stuff to stop happening. It's all very weird.
Hey @CompuIves any update here? We've been unable to load sandpack on Chrome 138 for several weeks now. Is there any mitigation that can be implemented on the codesandbox side?
I've spent quite some time debugging this already, but because the chrome devtools also hang when the problem happens, it's extremely hard to pinpoint. I would recommend to also respond to the chrome issue on their tracker to give it more importance.
Quick update is that I just tried upgrading to the latest Chrome 138.0.7204.158 and things are working again for me.
@CompuIves I'm now updated to Chrome 138.0.7204.169 and have a different problem (only in chrome, not on firefox? confused!) not sure if it's related, or should create a different issue? Lots of these types of messages in console and stuck ...
Access to fetch at 'https://prod-packager-packages.codesandbox.io/v2/packages/@babel/core/7.28.0.json' from origin 'https://2-19-8-sandpack.codesandbox.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
In the last day or so I did see the original problem less, but not 100% success rate. Might be clouded by the CORS issues I'm now seeing
update: looks like there's existing issues reported by other affected sandpack users https://github.com/codesandbox/sandpack/issues
If I hard reload, it works for a short time, but then this happens again (usually says 'starting' for too long, then app displays a full blank page .. something causes an eventual re-render and i see the error above. SO weird. Is there any link with [this report](https://issues.chromium.org/issues/429585228) or just coincidence on the blank page?
Firefox 140.0.4 , Windows OS 11