Inspector is stomping app's EmberENV

[ef4]

This is a non-deterministic failure that depends on how fast the inspector and the app load.

But if the app loads fast and the inspector loads slow, you can suddenly get bizarre results because the inspector completely replaces your window.EmberENV with its own here. This throws away your own settings.

I think it usually works because the inspector sets first, but that is apparently not guaranteed.

Probably it would be sufficient to make the inspector add properties to an existing EmberENV if it finds that one already exists.

[patricklx]

Probably need to insert this at the top?

ember-inspector/skeletons/web-extension/boot.js

Line 10 in ba75238

document.documentElement.appendChild(script);

Or another way to run code in user space .
Inspector must set that property before ember loads as far as i know

[patricklx]

@ef4 do you have an example online website where that happens?
this should not depend on how fast inspector loads. the boot.js file is inserted into all websites before the page loads the actual html.
while debugging i found that when boot.js runs, document.documentElement.children is empty. So the page did not yet load.
so even with
document.documentElement.appendChild(script) it will be at the top and run first.
edit: do you test with chrome or firefox?
edit2: firefox failed to release, so must be chrome

do you have other extensions installed?

[patricklx]

i confirmed it happens here:
https://ember-learn.github.io/ember-cli-addon-docs/

[nickschot]

We're likely seeing the same issue. Spotted because suddenly the optional feature application-template-wrapper was true, causing a visual bug due to the extra html element. Doesn't happen when ember-inspector is disabled.

[aoumiri]

Same here, we spend some time debugging this issue thinking it was our code, and that it was impacting our users, but we came to the conclusion that it was ember inspector that was breaking the app.

It happens on chromium browsers: with the ember inspector enabled, we can reproduce the issue, without it the app runs just fine.

Also, I confirm that the issue is random. Sometimes, the plugin's config overwrites the application's one. To reproduce it, you have to try multiple times a page refresh.

We also noticed that it's related to the application-template-wrapper param.

[ef4]

Spotted because suddenly the optional feature application-template-wrapper was true, causing a visual bug due to the extra html element.

Yes, the application-template-wrapper setting glitching can also cause this.element to be undefined in a rendering test, which was the case I first saw.