Ember-inspector: Error message: Ember.meta(...).peekDescriptors is not a function - Object are not shown for any ember component
Issue and Steps to Reproduce
- Open Ember Inspecter and click on any controller name to view the object
Your environment
ember-cli: 2.18.2
Browser : Chrome - Version 79.0.3945.79
Screenshots
ufthelp
All 14 comments
I have an identical situation. My Chrome version is 79.0.3945.88 64bit for Mac but same version of Ember.
BenReilly
on 24 Dec 2019
@chancancode is this likely another issue where the branching behavior is not working?
rwwagner90
on 26 Dec 2019
Quite possible, I can try to look into it tomorrow!
chancancode
on 26 Dec 2019
I have same issue in Data section. Chrome 79.0.3945.88 and MacOS 10.14.6
peyloride
on 26 Dec 2019
@peyloride what Ember version please?
rwwagner90
on 27 Dec 2019
@peyloride what Ember version please?
@rwwagner90 here it is;
ember-cli: 2.16.2
node: 8.16.0
But I can't reproduce the bug. It happens sometimes when I develop stuff, after refreshing chrome tab or using new one, it works again.
peyloride
on 27 Dec 2019
I have this same issue.
Ember: 2.13.3
Ember-CLI: 2.16
shoxter
on 27 Dec 2019
@wycats and I looked into this today. This is related to https://github.com/emberjs/ember-inspector/issues/1114. It's a very old problem unrelated to any recent changes – the problem always existed, it just was never noticed or root caused.
The problem is that, we always load the latest version of the inspector "app" (the UI) _and_ the most recent version of ember-debug. ember-debug is supposed to remain benign/"dormant" until the version-switching code runs. If it's determined that the host app's Ember version is supported by the inspector, both the inspector "app" and ember-debug will continue bootstrapping and ultimately renders the inspector UI. If it's determined that the host app's Ember version is unsupported, the inspector "app" refreshes into the older frozen version, inject another copy of the older ember-debug, and the process continues again.
The problem is that the "wrong" ember-debug we injected is really far from benign. We first noticed part of the problem in https://github.com/emberjs/ember-inspector/issues/1114, where the top-level code is being evaluated unexpectedly. The bigger problem is that we require a lot of modules, including the full adapter. Every module we required this way is going to remain in the loader's "instantiated modules" cache, and so when we later "re-inject" the correct version of ember-debug, some of the modules it defined are completely ignored, and the version from the newer (and incorrect) version of ember-debug will be used instead.
Essentially, this means we have a Frankenstein situation where we are running half of the code from the 2-7-0 ember-debug and half of the code from 3-4-0 ember-debug. In this case, it is causing issue now because ember-debug/object-inspector @ 3-4-0 is required at some point before ember-debug/object-inspector @ 2-7-0 is loaded, and there were some incompatible changes being made to that module recently (#1052 I believe). This problem is not really related to the change itself, but the change just happens to surface the problem.
Fixing this problem will probably require some bigger architectural changes around how Ember apps are detected and how ember-debug is injected. @wycats and I plan on working on this next week (we did a spike today and made pretty good progress).
In the mean time, if you are affected by this bug, you can manually downgrade to v3.12.5 following these instructions – just download the artifacts from the v3.12.5 instead of from the pull request.
chancancode
on 28 Dec 2019
@chancancode Thanks for great explanation, looking forward for full fix. If you guys need anything that I can do, just poke me.
peyloride
on 28 Dec 2019
Explanation is helpful. How goes the battle though?
arthur5005
on 27 Jan 2020
Just wondering if there's any progress here.
BenReilly
on 10 Feb 2020
@wycats has a fix, should be up sometime this week
chancancode
on 10 Feb 2020
Hi @ufthelp @BenReilly @peyloride @arthur5005! We released a new version that should have fixed the issue, it's been published to the chrome/firefox store and should auto-update in your browser. Can you give it a try? I'll close this issue for now, if you are still experiencing the issue after the update, please comment here and I'll reopen the issue.
chancancode
on 25 Feb 2020
@chancancode doing Godfrey's work! Works great now, thanks you so much 🙏.
arthur5005
on 25 Feb 2020
Related issues
brian-c
·
3Comments
gokatz
·
6Comments
lifeart
·
7Comments
seanmhoffman
·
4Comments
Turbo87
·
8Comments
Most helpful comment
@wycats and I looked into this today. This is related to https://github.com/emberjs/ember-inspector/issues/1114. It's a very old problem unrelated to any recent changes – the problem always existed, it just was never noticed or root caused.
The problem is that, we always load the latest version of the inspector "app" (the UI) _and_ the most recent version of ember-debug. ember-debug is supposed to remain benign/"dormant" until the version-switching code runs. If it's determined that the host app's Ember version is supported by the inspector, both the inspector "app" and ember-debug will continue bootstrapping and ultimately renders the inspector UI. If it's determined that the host app's Ember version is unsupported, the inspector "app" refreshes into the older frozen version, inject another copy of the older ember-debug, and the process continues again.
The problem is that the "wrong" ember-debug we injected is really far from benign. We first noticed part of the problem in https://github.com/emberjs/ember-inspector/issues/1114, where the top-level code is being evaluated unexpectedly. The bigger problem is that we
requirea lot of modules, including the full adapter. Every module we required this way is going to remain in the loader's "instantiated modules" cache, and so when we later "re-inject" the correct version of ember-debug, some of the modules it defined are completely ignored, and the version from the newer (and incorrect) version of ember-debug will be used instead.Essentially, this means we have a Frankenstein situation where we are running half of the code from the 2-7-0 ember-debug and half of the code from 3-4-0 ember-debug. In this case, it is causing issue now because
ember-debug/object-inspector @ 3-4-0is required at some point beforeember-debug/object-inspector @ 2-7-0is loaded, and there were some incompatible changes being made to that module recently (#1052 I believe). This problem is not really related to the change itself, but the change just happens to surface the problem.Fixing this problem will probably require some bigger architectural changes around how Ember apps are detected and how ember-debug is injected. @wycats and I plan on working on this next week (we did a spike today and made pretty good progress).
In the mean time, if you are affected by this bug, you can manually downgrade to v3.12.5 following these instructions – just download the artifacts from the v3.12.5 instead of from the pull request.