Only application present in View Tree

[Frozenfire92]

I have been working on upgrading to 1.13 and have noticed that my view tree is quite off. I tried cloning and building from source but the same issue

[Frozenfire92]

Looking more at the view and then in rendering performance, it doesn't seem to be recognizing the views/templates at all. For example this is rendering performance.

However if I go into the Routes tab the currently active route is bolded

Some more info incase it helps

Ember Inspector 1.8.2
Ember 1.13.3
Ember Data 1.0.0-beta.18
jQuery 2.0.3

Looking at this #248 it may be related to @ToddSmithSalter's solution

UPDATE:

I have checked through the Routes tab and all the controllers and nothing seemed to be out of line. I also tried going back to the earlier versions but it breaks specifically at 1.13.0

[Frozenfire92]

I will note that our app heavily relies on views, would having these be the cause?

[philrenaud]

👍

[teddyzeenny]

@Frozenfire92 I see an application view in the view tree. What's missing, the index view? Or are there other views that should be visible?
Are you using ember-cli?
Can you try upgrading to 1.13.6?
Is it something you can reproduce in a jsbin or online repo?

[Frozenfire92]

Hey @teddyzeenny

You are correct that more views should be visible. If you look the Application view in the view tree also says its an inline template and its view/component is an unknown mixin

I've attached a screenshot of what it looks like in 1.12 and below

Upgrading to 1.13.6 didn't work unfortunately. I will try and reproduce it in jsbin now. Also there was one other user on the forums who had this here I will try and ping him in here for more info

[Frozenfire92]

I wasn't able to reproduce immediately with a jsbin

http://emberjs.jsbin.com/bovusipafa/2

this is much simpler than our app, I will try and add more characteristic things our app has when I have time

[Frozenfire92]

Tried upgrading to 1.13.8 but the issue persists. I didn't see your comment about ember-cli, we are using grunt with emberTemplates and concat. In the discussion linked above the other person who had the issue was using ember-cli

[rwjblue]

@Frozenfire92 - Can you confirm you are on 1.9.x of the inspector? It fixed a number of issues with the view tree, so I just want to make sure we are talking about the latest release version....

[Frozenfire92]

Yep I'm on 1.9.0

Edit: Just tried on firefox aswell and the same thing occurs

[hrfuller]

I am experiencing the same issue on Firefox:

Ember : 1.13.8
Ember Data : 1.13.9
Ember-CLI: 1.13.8

Generally the only line in the view tree is the application route. A few routes in the app will cause a nested route to appear under the application route. Once there is anything nested under the application route switching routes in the app does not cause the view-tree name column to update for that nested route. The controller column will however switch properly, while the view does not.
On 'analytics' route:

Change to 'campaigns' route:

[Frozenfire92]

Still present in ember 1.13.9

[JDillon522]

Currently experiencing the same issue.

Ember Inspector - 1.9.0
Ember - 1.12.1
Ember Data - 1.0.0-beta.19.2
jQuery - 1.11.3
Ember Simple Auth - 0.8.0

While on the billing route:

Confirming I am on the billing route:

This is also appearing on my team member's machines.

[JDillon522]

Has anyone tinkered with this at all? I'm also using liquid-fire and all the liquid-fire components show up when I click on the components box, but none of my controllers / routes

[JDillon522]

Confirmed that this also happens in firefox for me as well

[formigarafa]

I created a almost empty project and I run it via both: ember-cli and ember-rails
both using ember 1.13
the ember-cli one works fine, but the ember rails one does not display the correct view tree.

[formigarafa]

digging a little in the inspector code, I found that templates compiled with ember-rails does not include the attribute meta.moduleName so the templates cannot be inferred.

here:
https://github.com/emberjs/ember-inspector/blob/master/ember_debug/view-debug.js#L829

[nightire]

I can confirm one of the reason is ember-liquid-fire, or other addons relied on it, more importantly, a .xxx-liquid-xxx div that rendered before the first .ember-view of ember application.

I found that if you drag the .xxx-liquid-xxx (sorry I've forgot the class name because it has been removed now) element down to the first .ember-view (chrome dev tool can let you do that), then the view tree will be complete in Ember Inspector. This maybe because ember-liquid-fire render its wrapper by using body.insertBefore or something similar that prevent Ember Inspector parse the view tree correctly.

I guess this is some sort of edge case of view tree rendering parse, for now I just remove all addons that rely on ember-liquid-fire include itself.

Don't sure other possibilities, just my personal experience.

[formigarafa]

Now I have just made another test to confirm.
I created a ember app with ember cli.
worked as expected (because it includes template name in a meta object with compiled templates).

meta: {
        "revision": "Ember@1.13.11",
        ...
        "moduleName": "treeviewinspectortest/templates/index.hbs"
      },

Then I manually removed that moduleName entry from meta in the compiled template.
Now, the app still runs fine. But the view tree inspector only displays the Application with (inline) as template and I get no other item in the tree.

And that is how rails-ember compiles their templates, without inclusion of moduleName in their output.

[formigarafa]

I have changed the template compilation process for ember-rails with the changes above, and now the view tree inspector works fine with ember 1.13.

When the compilation happens using HTMLBars.compile I added an extra parameter to include the mentioned meta.moduleName with template name.

To do so, barber needs to accept compilation options (tchak/barber#53) and ember-handlebars-template need to provide them (tricknotes/ember-handlebars-template#14).

[tricknotes]

Now I released a ember-handlebars-template@0.6.0 thanks to @formigarafa .
It works fine to me.

Could someone try it?

[lolmaus]

I also experience this issue caused by Liquid Fire. I confirm that dragging the liquid div below the application div as @nightire suggests is a valid workaround.

Can you please fix this?

[lolmaus]

PLEASE, this is so annoying! >_<

[lolmaus]

I've started a bounty for this issue: https://freedomsponsors.org/issue/781/only-application-present-in-view-tree

Please join! $10 so far.

[davewasmer]

Looks like this is the problematic line:

let applicationViewId = $(emberApp.rootElement).find('> .ember-view').attr('id');

Ember Inspector seems to assume that the views will form a tree with a single root view, whose element will be the only element at that level of the DOM with an .ember-view class.

However, liquid-fire and/or ember-wormhole violate this assumption with their "warping" behavior that places ember view containing elements directly below the app's rootElement (i.e. as siblings of the application view).

Manually moving these warped elements after the application view in the Chrome inspector works around this, because the above CSS selector then selects the appropriate element as the application view.

To solve this, it seems like we have a few options:

1. Ember Inspector can be refactored to be able to accommodate a view tree with multiple roots. Not sure how big a change this would be - I'm unfamiliar with the codebase.
2. We could try to use the app's rootElement as a "pseudo-view" that would give us a single root view tree, but we'd have to account for there not actually being an ember view there.

I was going to take a stab at this (option 1 specifically), but I'm unable to get a clean checkout to build on my local machine (I'll file a separate issue for that).

[lolmaus]

We could simply update this selector .find('> .ember-view') to ignore Liquid Fire/Wormhole elements?

[davewasmer]

@lolmaus we could, but that would (a) prevent devs from inspecting the warped views themselves, and (b) tightly couple ember inspector to liquid-fire & wormhole. If those addons ever changed their DOM structure, inspector might then need to change. And there may be other, less popular addons that do similar things (now or in the future) - how do we make sure those all are supported?

Ultimately, I think the root problem is the mismatch between the inspector's ideas of the view tree (that it has a single root) and reality (there can be multiple roots). I think the best way to avoid more bugs / special casing in the future is to change inspector to match the reality of Ember's view system.

[lolmaus]

@davewasmer Sure, but having that workaround is better than nothing, right? We could do that and keep looking for a better solution.

[davewasmer]

@lolmaus personally, I think the "move the warped elements to after the application's element in Elements panel" is enough of a workaround to avoid shipping an intermediate solution that would be replaced shortly thereafter by a long term solution.