Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No binding context on what should be valid nodes #14

Open
JNotelddim opened this issue Jan 18, 2019 · 4 comments
Open

No binding context on what should be valid nodes #14

JNotelddim opened this issue Jan 18, 2019 · 4 comments

Comments

@JNotelddim
Copy link

I'm submitting a bug report

  • Library Version:
    1.3.0

Please tell us about your environment:

  • Operating System:
    Windows 10

  • Node Version:
    8.11.3

  • NPM Version:
    6.1.0

  • JSPM OR Webpack AND Version
    webpack-cli 2.1.5
    (webpack is running through Visual Studio - I don't have webpack-cli installed regularly for use, so if i go into cmd or bash and run webpack it just tells me i don't have the cli installed.
    our package.json says "webpack": "^4.1.1" though)

  • Browser:
    Google Chrome | 71.0.3578.98 (Official Build) (64-bit)

  • Language:
    TypeScript 2.7.2

Current behavior:
Selecting node in 'Elements' debugger panel fails to show binding context.
image
You can see here, I've selected one of the nodes within my custom element. I've been using this extension for months and have never had an issue with it not giving me the binding context correctly - but the past few days it's been happening regularly. No matter what I select I don't get a binding context until I close the tab and reopen the app in a new tab. But even then, it seems to break pretty quickly.

Expected behavior?
The binding-context, etc should show up when I select an appropriate node.
image

Note
I'm not experienced with the inner workings of chrome extensions- but if there's more info I can provide (particular logs, etc) please let me know.

@JNotelddim
Copy link
Author

Maybe this is a chrome issue though?
I've also been having issues with my code not updating properly in the source view of the debugger, and that doesn't work again until I reopen the debugger.
(and I'm now finding reopening the debugger is working for getting Aurelia Inspector working again too)

So this isn't as big of a deal, now that I've realized I can just reopen the debugger - but I'd think it'd still be worth at least determining if it's a chrome or aurelia inspector issue, or something else?

@bigopon
Copy link
Member

bigopon commented Jan 22, 2019

It's not immediately obvious why it works in that way, but I can have a look sometimes later today

@EisenbergEffect
Copy link
Contributor

EisenbergEffect commented Jan 22, 2019

Thanks for digging in @JNotelddim. Debugging and developing Chrome plugins can be a bit of a pain and very tricky to track down some issues. @bigopon I haven't looked at this code in a while. If you want to jump in and take a look, that would be appreciated. You've much more recently dug into vCurrent templating so you're probably the best equipped to track any issues down if it's in our code.

@Alexander-Taran
Copy link

Inspector moved to https://github.com/brandonseydel/aurelia-inspector

@bigopon can be closed.. I guess

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants