Add __VUE_DEVTOOLS_CONTEXT__ to allow for iframe compatibility

[matt-oconnell]

Hi, I'm currently creating this PR as a discussion point to possibly solve some of the issues around using Devtools to identify apps within iframes 1, 2 (last bullet point).

The stopgap solution I'm proposing here would check for a global __VUE_DEVTOOLS_CONTEXT__ variable on the target document. This would allow for an application like storybook or vue-play to define the context in which the devtools would run. I.e. https://github.com/storybooks/storybook/pull/1376/files

This may not be the perfect way to go but it's currently the solution I'm using locally to develop and I figured it might be helpful to bring up here.

[posva]

Well, thanks for starting the discussion 🙂
Because storybook it's starting to support Vue, this is something we really want to start looking at. I'll probably look for a proper solution to make the devtools work with iframes (something like choosing what the context is). I think it's ok to use this locally for testing stuff until then

[kazupon]

I hope that vue-devtools for storybook supporting, due to collaborate vue supporting of storybook.
storybookjs/storybook#1267

In storybook 3.2, will be release for vue supporting. 😉

[miljan-aleksic]

Why is this not going forward?

[posva]

It does, but very slowly, because I don't have as much time as I would like to 😞

[ndelangen]

Really appreciate the hard work you're putting in this @posva

[LinusBorg]

@miljan-aleksic Just as a side note, a better way to ask your question would be something: "I am very interested in seeing this completed. How can I help in getting this to move forward?"

[miljan-aleksic]

@posva, @LinusBorg, seems I spend daily too many hours answering tickets and helping others that I have forgotten how to ask for help my self. Sorry if my question was too raw, I didn't imply anything with it, didn't even assume somebody was or not working on it, just wanted to know if there is any update on this topic that is important, but seems have low priority.

[LinusBorg]

@miljan-aleksic Thanks for understanding, and no worries, I'm guilty of that too from time to time. We all just need a little reminder sometimes, and that's ok.

[posva]

In case anyone wants to look what is working, there's an iframes branch. Currently, we can select iframes (although it seems to be failing in some scenarios, namely with storybook) and they appear in the devtools but they do not update because there's a linking part missing. Because of the same reason, vuex and events do not work either

[ndelangen]

Something I can do on the storybook side?

[posva]

not at the moment, I'll ping you in the Discord server if something arises 🙂

[davinov]

I've started to work this weekend on this (very work in progress - chrome only: davinov@5ec21a8)
As iframe to parent scripts communication seems not that possible, I suggest to create one backend/port by frame ("allFrames": true) and switch the ports when we select the frame.
I got my branch kinda working on chrome with this system.
It relies on frameURL to identify the frame, which could be not unique enough (imagine a case where multiple iframes of the same URL would be embedded - but yes, quite rare I guess). However, I couldn't manage to get the frameId somehow, so I stayed with that.
I took some inspiration from Maluen/Backbone-Debugger#24 (comment) which lists how they made it in the Ember debugger.

@posva : we could take some time time to discuss this in the week if you're available

[ndelangen]

It relies on frameURL to identify the frame, which could be not unique enough (imagine a case where multiple iframes of the same URL would be embedded - but yes, quite rare I guess).

Actually in the case of Living Styleguides.. this can happen.

Storybook doesn't do this YET, but it could eventually. (showing multiple previews with different sizes to develop responsive components better)

[davinov]

Hehe, thanks to indicate that!

With further research, I think it can be achieved that by replacing inspectedWindow.eval by chrome.tabs.executeScript and chrome.webNavigation.getAllFrames(tabId) to find the frame ids intsead of listening to onResourcesAdded.
The we need to figure out which events to use for frame adding/removal (maybe we can keep the actual onRessourceAdded listener) and when the frame is navigated (for this, chrome.webNavigation.onCommitted seems to be the right event).

[kazupon]

How is this going?

[posva]

@davinov got a bit further, I pushed my work in a branch here but I simply don't have the time at the moment 🙁

[kazupon]

@posva Thank you for your reply!

@davinov
Are you working on the following branch?
https://github.com/davinov/vue-devtools/tree/iframes

I would like to help it due to be able make time.

[davinov]

@kazupon Yes I was testing on this branch.
I had no time these past weekends to make any progress :/

@posva I should take some time to look at your work :)

[michalsnik]

Hey guys 👋
First of all good job so far! I'm excited to see it working with Storybook 😍

@posva are you going to find some time in the next week or two to take a look around or should we look for someone to take over this topic?

@davinov have you got a chance to take a look at @posva's work already?

[ndelangen]

Wait whut, this is working now?

[LinusBorg]

What gives you the impression?

[ndelangen]

I'm excited to see it working with Storybook

[LinusBorg]

You can be excited for things not yet existing / working ;)

If you read the next sentence, he's asking posva if he can continue work on this or someone else should pick up. That would not make sense if it worked already, would it?

[zephraph]

Could we move forward with this PR? storybookjs/storybook#1376 was merged from the storybook side. This isn't a be-all-end-all solution, but it provides more capabilities than exist now. We could roll forward with a different iframe selector experience at some later point.

[zephraph]

@Akryum what do you think about merging this? At the very least it doesn't hurt anything. It gives the capability to vue-devtools with storybook today.

[y-nk]

Hi all !

In an effort to push this forward, i've started to work on this matter in my fork. After a night of hack, the most basic example looks like working , but I would like more feedbacks before going any further. I had to implement a nasty hack but i think this feature cannot work without it, or at least something cleaner that looks like it.

Both Vue.js and VueX relies on a window getter named __VUE_DEVTOOLS_GLOBAL_HOOK__ to initialize devtools related functions at the time of loading and construction, but not later. It makes it impossible to switch between iframes with concurrent Vue.js / VueX instances running.

You can see calls to the devtools in the init process of Vue.js (here) and in the process of construction of a VueX Store(here).

That makes it not possible to use the VueX, router, and events part of the devtools in an iframe environment without patching Vue.js and VueX. I investigated few ways to do achieve this :

• The only way to do it clean would be for the devtools to inject getter returning its hook before the loading all iframes, so the libraries could pick it before init, but it sounds impossible.

• The libraries could leave a trace of their instances in the top window context. The caveat is that it's more code to add in Vue.js and VueX to find out where to drop the package, but it makes more sense, as there's no need for recursive searching from the devtools part : it just picks whatever is there.

• The libraries (Vue.js, VueX) could leave a trace of their instances in their execution context (iframe), and then the devtools should go, dig and pick up. It's possible to do so, but then we would need to modify Vue.js and VueX builds to leave that trace, with a proper boolean to disable this feature.

I tried to implement 2nd proposition with postMessage but it seems impossible since Vue.js main object isn't clonable (apparently, there was an error thrown while I tried.). I also tried by looking for the top level window, which was pretty easy, but the implementation didn't feel right.

So, I went for the 3rd proposition instead : for a soft patch, I implemented how Vue.js and VueX could leave their instance to be debugged here but i think we could do better if we were to modify the builds.

Then, It was relatively easy to patch the devtools ; that said, i think it should be re-written with async hooking taken in consideration, as well as for Vue.js and VueX. For example about the latter, I think this should be deleted in order to avoid nasty hack in the devtools.

On a side note, I'm sorry that I couldn't pick up on @posva branch but it looked a bit far from dev branch, so I tried directly from it instead.

There are for sure lots of things to do, and to clean in order to make this tool works with iframes.

Please, let me know what you think :)

[gapipro]

Can we get this moving again?

[y-nk]

@gapipro i could try to make a proper branch and propose a PR, maybe this could move faster this way.

although, i think the architecture of this app is quite something to rework on. I'd like to propose my help, but i think there's a lot to do to provide a better structure and readability. Let me know in what sense i could help to make it move forward.

[Aaron-Pool]

Could we get some sort of direction from the Vue-devtools team on what is needed here? I might be willing to pitch in and help, but it seems like right now any effort might just be a waste, because it's not clear what path forward is acceptable to the devtools team. Or even if there's sufficient interest in getting outside contributions merged in to address the issue. Any feedback would be super appreciated 👍

[LinusBorg]

@Akryum @posva can you chime in?

[posva]

Isn't this outdated now that remote devtools exist? wasn't it made by @michalsnik and @znck ?

[Akryum]

You should be able to debug anything with the remote devtools.

[Aaron-Pool]

@posva @Akryum @LinusBorg I'm not sure what you guys are referring to. If you're talking about the vue stand alone electron app, and placing the <script src="http://localhost:8098"></script> in the header of the iframe we want to debug, that doesn't work either. Devtools will connect, but comes up completely blank.

[LinusBorg]

That's what they were referring to, yeah.

If that sometimes works and sometimes doesn't, it still seems to work better than what we have concerning this PR right here, right?

So if we move to improve it, we will probably get more progress if we concentrate on the remote devtools implementation.

[Aaron-Pool]

@LinusBorg I'm fine with that as well. I'm pretty confident it worked at some point with the electron shell early last year, but it's been broken (as far as I can tell) for a good handful of months now. Let me know if there's anything I can do, here or elsewhere, to help things move along.

[y-nk]

@Aaron-Pool if there's a repo to work on a fresh version, i'm willing to help too.

[lloydjatkinson]

Any updates on this? Where or who is best to ask? It it a devtools issue or storybook issue?

[miljan-aleksic]

In Storybook 5 you can launch the current story iframe on an external browser tab where the Vue devtools will work as expected. Is a good workaround and it actually make sense to remove the Storybook context when using a 3rd party tool.

[nchudleigh]

Thanks @miljan-aleksic, should be noted that this only works locally, if you run the static build storybook sets Vue to production mode and Dev Tools are disabled.

[lk77]

Any news on that ?
it would be great to be able to right click on a iframe and change the context of vue dev tools.

[bahmutov]

I have tried the small change in the PR using Cypress, funny, the badge says "Vue.js not detected", yet the Vue DevTools is showing the component and its state, but not the Vuex store there.

[humorHan]

so? When can I use it？