Error message: Ember.meta(...).peekDescriptors is not a function - Object are not shown for any ember component #1120
Comments
|
I have an identical situation. My Chrome version is 79.0.3945.88 64bit for Mac but same version of Ember. |
|
@chancancode is this likely another issue where the branching behavior is not working? |
|
Quite possible, I can try to look into it tomorrow! |
|
I have same issue in Data section. Chrome 79.0.3945.88 and MacOS 10.14.6 |
|
@peyloride what Ember version please? |
@rwwagner90 here it is; 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. |
|
I have this same issue. Ember: 2.13.3 |
|
@wycats and I looked into this today. This is related to #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 #1114, where the top-level code is being evaluated unexpectedly. The bigger problem is that we 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 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 Thanks for great explanation, looking forward for full fix. If you guys need anything that I can do, just poke me. |
|
Explanation is helpful. How goes the battle though? |
|
Just wondering if there's any progress here. |
|
@wycats has a fix, should be up sometime this week |
wycats
added a commit
that referenced
this issue
Feb 12, 2020
As @chancancode explained in #1120[1], the injected debug code previously did too much work in order to report a version miss. To help understand what went wrong, I'll give an abridged version of the boot-up protocol, and how the fallback logic fits in. 1. The Ember inspector application boots up inside of a devtools iframe, and injects the version of `ember_debug.js` for the latest version of the Ember inspector. 2. `ember_debug.js` to become aware of any supported version of Ember, and when that happens, it checks whether the version of Ember on the current page is supported by the current version of `ember_debug.js`. 3. If it matches, everything proceeds as usual, and `ember_debug.js` starts communicating with the inspector pane. 4. If it doesn't match, `ember_debug.js` sends a `version-mismatch` message to the inspector pane along with the current version of Ember used on the current page. The inspector pane then calculates which version of the inspector to use (currently either `0-0-0` for Ember 0.0 to Ember 2.6 or `2-7-0` for Ember 2.8 to Ember 3.2). When this happens, the inspector navigates itself to the older version of the inspector, allowing that version to bootstrap itself. Note that the inspector uses the Ember registry and loader to register its modules, so any modules for the latest version of ember_debug will *still be registered* when the older version of `ember_debug.js` is evaluated. This is not intrinsically a problem, since the calls to `define` in the new version of `ember_debug.js` will replace the old modules. Any modules that were present in the latest version but not the previous version will still be registered, but won't be used by the older code. The problem with all of that is that if any module is *required* in the process of reporting the version miss, the module's exports will remain cached in Ember's loader. Replacing the module with new source code has no effect, because the next time someone tries to require the module, it will just return the old cached exports, and the new `define` is completely ignored. This means that, depending on which code is required as part of reporting the version miss, a random Frankenstein combination of modules will be used at runtime. It should come as no surprise that this could have problems. The reason that it didn't cause any issues until recently is a coincidence: the assortment of modules in question happened to work well enough to avoid any problems that incited a user to report the bug. The solution to the problem in this commit is to completely avoid requiring any modules before the version is correctly matched. There were three modules previously required: 1. Two utility modules: `on-ready` and `version`. These modules were small so I inlined the code next to the version reporting logic. 2. The ember_debug adapter. This is a much thornier dependency, because it sucks in a whole bunch of additional dependencies and is the root cause of the current issue. I addressed this dependency by hand-coding just enough logic to create a `MessageChannel`, post it to the current window, and `postMessage` a `version-mismatch` message through the channel. This works as long as the adapter uses a `MessageChannel` to communicate the version mismatch. This is how `web-extension.js` works, which covers Chrome, Firefox, Edgium, and remote debugging using the remote debugging protocol. It does not cover other backends, but those backends are currently broken for other reasons. It doesn't substantially burden the work of making other backends work again, it simply constrains backends to use a `MessageChannel` (posted to the inspected app's window) to communicate version mismatches. It doesn't otherwise constrain any adapter functionality in `ember_debug` or the Ember Inspector. If this constraint isn't acceptable for a future backend, we could also support alternative ways of communicating the version mismatch, as long as that didn't require the version reporting code to load in the entire adapter module. [1]: #1120 (comment)
wycats
added a commit
that referenced
this issue
Feb 20, 2020
As @chancancode explained in #1120[1], the injected debug code previously did too much work in order to report a version miss. To help understand what went wrong, I'll give an abridged version of the boot-up protocol, and how the fallback logic fits in. 1. The Ember inspector application boots up inside of a devtools iframe, and injects the version of `ember_debug.js` for the latest version of the Ember inspector. 2. `ember_debug.js` to become aware of any supported version of Ember, and when that happens, it checks whether the version of Ember on the current page is supported by the current version of `ember_debug.js`. 3. If it matches, everything proceeds as usual, and `ember_debug.js` starts communicating with the inspector pane. 4. If it doesn't match, `ember_debug.js` sends a `version-mismatch` message to the inspector pane along with the current version of Ember used on the current page. The inspector pane then calculates which version of the inspector to use (currently either `0-0-0` for Ember 0.0 to Ember 2.6 or `2-7-0` for Ember 2.8 to Ember 3.2). When this happens, the inspector navigates itself to the older version of the inspector, allowing that version to bootstrap itself. Note that the inspector uses the Ember registry and loader to register its modules, so any modules for the latest version of ember_debug will *still be registered* when the older version of `ember_debug.js` is evaluated. This is not intrinsically a problem, since the calls to `define` in the new version of `ember_debug.js` will replace the old modules. Any modules that were present in the latest version but not the previous version will still be registered, but won't be used by the older code. The problem with all of that is that if any module is *required* in the process of reporting the version miss, the module's exports will remain cached in Ember's loader. Replacing the module with new source code has no effect, because the next time someone tries to require the module, it will just return the old cached exports, and the new `define` is completely ignored. This means that, depending on which code is required as part of reporting the version miss, a random Frankenstein combination of modules will be used at runtime. It should come as no surprise that this could have problems. The reason that it didn't cause any issues until recently is a coincidence: the assortment of modules in question happened to work well enough to avoid any problems that incited a user to report the bug. The solution to the problem in this commit is to completely avoid requiring any modules before the version is correctly matched. There were three modules previously required: 1. Two utility modules: `on-ready` and `version`. These modules were small so I inlined the code next to the version reporting logic. 2. The ember_debug adapter. This is a much thornier dependency, because it sucks in a whole bunch of additional dependencies and is the root cause of the current issue. I addressed this dependency by hand-coding just enough logic to create a `MessageChannel`, post it to the current window, and `postMessage` a `version-mismatch` message through the channel. This works as long as the adapter uses a `MessageChannel` to communicate the version mismatch. This is how `web-extension.js` works, which covers Chrome, Firefox, Edgium, and remote debugging using the remote debugging protocol. It does not cover other backends, but those backends are currently broken for other reasons. It doesn't substantially burden the work of making other backends work again, it simply constrains backends to use a `MessageChannel` (posted to the inspected app's window) to communicate version mismatches. It doesn't otherwise constrain any adapter functionality in `ember_debug` or the Ember Inspector. If this constraint isn't acceptable for a future backend, we could also support alternative ways of communicating the version mismatch, as long as that didn't require the version reporting code to load in the entire adapter module. [1]: #1120 (comment) (cherry picked from commit 9022a02)
|
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 doing Godfrey's work! Works great now, thanks you so much 🙏. |
nummi
pushed a commit
to nummi/ember-inspector
that referenced
this issue
Apr 1, 2020
As @chancancode explained in emberjs#1120[1], the injected debug code previously did too much work in order to report a version miss. To help understand what went wrong, I'll give an abridged version of the boot-up protocol, and how the fallback logic fits in. 1. The Ember inspector application boots up inside of a devtools iframe, and injects the version of `ember_debug.js` for the latest version of the Ember inspector. 2. `ember_debug.js` to become aware of any supported version of Ember, and when that happens, it checks whether the version of Ember on the current page is supported by the current version of `ember_debug.js`. 3. If it matches, everything proceeds as usual, and `ember_debug.js` starts communicating with the inspector pane. 4. If it doesn't match, `ember_debug.js` sends a `version-mismatch` message to the inspector pane along with the current version of Ember used on the current page. The inspector pane then calculates which version of the inspector to use (currently either `0-0-0` for Ember 0.0 to Ember 2.6 or `2-7-0` for Ember 2.8 to Ember 3.2). When this happens, the inspector navigates itself to the older version of the inspector, allowing that version to bootstrap itself. Note that the inspector uses the Ember registry and loader to register its modules, so any modules for the latest version of ember_debug will *still be registered* when the older version of `ember_debug.js` is evaluated. This is not intrinsically a problem, since the calls to `define` in the new version of `ember_debug.js` will replace the old modules. Any modules that were present in the latest version but not the previous version will still be registered, but won't be used by the older code. The problem with all of that is that if any module is *required* in the process of reporting the version miss, the module's exports will remain cached in Ember's loader. Replacing the module with new source code has no effect, because the next time someone tries to require the module, it will just return the old cached exports, and the new `define` is completely ignored. This means that, depending on which code is required as part of reporting the version miss, a random Frankenstein combination of modules will be used at runtime. It should come as no surprise that this could have problems. The reason that it didn't cause any issues until recently is a coincidence: the assortment of modules in question happened to work well enough to avoid any problems that incited a user to report the bug. The solution to the problem in this commit is to completely avoid requiring any modules before the version is correctly matched. There were three modules previously required: 1. Two utility modules: `on-ready` and `version`. These modules were small so I inlined the code next to the version reporting logic. 2. The ember_debug adapter. This is a much thornier dependency, because it sucks in a whole bunch of additional dependencies and is the root cause of the current issue. I addressed this dependency by hand-coding just enough logic to create a `MessageChannel`, post it to the current window, and `postMessage` a `version-mismatch` message through the channel. This works as long as the adapter uses a `MessageChannel` to communicate the version mismatch. This is how `web-extension.js` works, which covers Chrome, Firefox, Edgium, and remote debugging using the remote debugging protocol. It does not cover other backends, but those backends are currently broken for other reasons. It doesn't substantially burden the work of making other backends work again, it simply constrains backends to use a `MessageChannel` (posted to the inspected app's window) to communicate version mismatches. It doesn't otherwise constrain any adapter functionality in `ember_debug` or the Ember Inspector. If this constraint isn't acceptable for a future backend, we could also support alternative ways of communicating the version mismatch, as long as that didn't require the version reporting code to load in the entire adapter module. [1]: emberjs#1120 (comment)
nummi
pushed a commit
to nummi/ember-inspector
that referenced
this issue
Apr 5, 2020
As @chancancode explained in emberjs#1120[1], the injected debug code previously did too much work in order to report a version miss. To help understand what went wrong, I'll give an abridged version of the boot-up protocol, and how the fallback logic fits in. 1. The Ember inspector application boots up inside of a devtools iframe, and injects the version of `ember_debug.js` for the latest version of the Ember inspector. 2. `ember_debug.js` to become aware of any supported version of Ember, and when that happens, it checks whether the version of Ember on the current page is supported by the current version of `ember_debug.js`. 3. If it matches, everything proceeds as usual, and `ember_debug.js` starts communicating with the inspector pane. 4. If it doesn't match, `ember_debug.js` sends a `version-mismatch` message to the inspector pane along with the current version of Ember used on the current page. The inspector pane then calculates which version of the inspector to use (currently either `0-0-0` for Ember 0.0 to Ember 2.6 or `2-7-0` for Ember 2.8 to Ember 3.2). When this happens, the inspector navigates itself to the older version of the inspector, allowing that version to bootstrap itself. Note that the inspector uses the Ember registry and loader to register its modules, so any modules for the latest version of ember_debug will *still be registered* when the older version of `ember_debug.js` is evaluated. This is not intrinsically a problem, since the calls to `define` in the new version of `ember_debug.js` will replace the old modules. Any modules that were present in the latest version but not the previous version will still be registered, but won't be used by the older code. The problem with all of that is that if any module is *required* in the process of reporting the version miss, the module's exports will remain cached in Ember's loader. Replacing the module with new source code has no effect, because the next time someone tries to require the module, it will just return the old cached exports, and the new `define` is completely ignored. This means that, depending on which code is required as part of reporting the version miss, a random Frankenstein combination of modules will be used at runtime. It should come as no surprise that this could have problems. The reason that it didn't cause any issues until recently is a coincidence: the assortment of modules in question happened to work well enough to avoid any problems that incited a user to report the bug. The solution to the problem in this commit is to completely avoid requiring any modules before the version is correctly matched. There were three modules previously required: 1. Two utility modules: `on-ready` and `version`. These modules were small so I inlined the code next to the version reporting logic. 2. The ember_debug adapter. This is a much thornier dependency, because it sucks in a whole bunch of additional dependencies and is the root cause of the current issue. I addressed this dependency by hand-coding just enough logic to create a `MessageChannel`, post it to the current window, and `postMessage` a `version-mismatch` message through the channel. This works as long as the adapter uses a `MessageChannel` to communicate the version mismatch. This is how `web-extension.js` works, which covers Chrome, Firefox, Edgium, and remote debugging using the remote debugging protocol. It does not cover other backends, but those backends are currently broken for other reasons. It doesn't substantially burden the work of making other backends work again, it simply constrains backends to use a `MessageChannel` (posted to the inspected app's window) to communicate version mismatches. It doesn't otherwise constrain any adapter functionality in `ember_debug` or the Ember Inspector. If this constraint isn't acceptable for a future backend, we could also support alternative ways of communicating the version mismatch, as long as that didn't require the version reporting code to load in the entire adapter module. [1]: emberjs#1120 (comment)
patricklx
pushed a commit
to patricklx/ember-inspector
that referenced
this issue
Sep 19, 2022
As @chancancode explained in emberjs#1120[1], the injected debug code previously did too much work in order to report a version miss. To help understand what went wrong, I'll give an abridged version of the boot-up protocol, and how the fallback logic fits in. 1. The Ember inspector application boots up inside of a devtools iframe, and injects the version of `ember_debug.js` for the latest version of the Ember inspector. 2. `ember_debug.js` to become aware of any supported version of Ember, and when that happens, it checks whether the version of Ember on the current page is supported by the current version of `ember_debug.js`. 3. If it matches, everything proceeds as usual, and `ember_debug.js` starts communicating with the inspector pane. 4. If it doesn't match, `ember_debug.js` sends a `version-mismatch` message to the inspector pane along with the current version of Ember used on the current page. The inspector pane then calculates which version of the inspector to use (currently either `0-0-0` for Ember 0.0 to Ember 2.6 or `2-7-0` for Ember 2.8 to Ember 3.2). When this happens, the inspector navigates itself to the older version of the inspector, allowing that version to bootstrap itself. Note that the inspector uses the Ember registry and loader to register its modules, so any modules for the latest version of ember_debug will *still be registered* when the older version of `ember_debug.js` is evaluated. This is not intrinsically a problem, since the calls to `define` in the new version of `ember_debug.js` will replace the old modules. Any modules that were present in the latest version but not the previous version will still be registered, but won't be used by the older code. The problem with all of that is that if any module is *required* in the process of reporting the version miss, the module's exports will remain cached in Ember's loader. Replacing the module with new source code has no effect, because the next time someone tries to require the module, it will just return the old cached exports, and the new `define` is completely ignored. This means that, depending on which code is required as part of reporting the version miss, a random Frankenstein combination of modules will be used at runtime. It should come as no surprise that this could have problems. The reason that it didn't cause any issues until recently is a coincidence: the assortment of modules in question happened to work well enough to avoid any problems that incited a user to report the bug. The solution to the problem in this commit is to completely avoid requiring any modules before the version is correctly matched. There were three modules previously required: 1. Two utility modules: `on-ready` and `version`. These modules were small so I inlined the code next to the version reporting logic. 2. The ember_debug adapter. This is a much thornier dependency, because it sucks in a whole bunch of additional dependencies and is the root cause of the current issue. I addressed this dependency by hand-coding just enough logic to create a `MessageChannel`, post it to the current window, and `postMessage` a `version-mismatch` message through the channel. This works as long as the adapter uses a `MessageChannel` to communicate the version mismatch. This is how `web-extension.js` works, which covers Chrome, Firefox, Edgium, and remote debugging using the remote debugging protocol. It does not cover other backends, but those backends are currently broken for other reasons. It doesn't substantially burden the work of making other backends work again, it simply constrains backends to use a `MessageChannel` (posted to the inspected app's window) to communicate version mismatches. It doesn't otherwise constrain any adapter functionality in `ember_debug` or the Ember Inspector. If this constraint isn't acceptable for a future backend, we could also support alternative ways of communicating the version mismatch, as long as that didn't require the version reporting code to load in the entire adapter module. [1]: emberjs#1120 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue and Steps to Reproduce
Your environment
ember-cli: 2.18.2
Browser : Chrome - Version 79.0.3945.79
Screenshots
The text was updated successfully, but these errors were encountered: