Currently the Vue Devtools do not recognize vue roots within iframes.
There is work being done on storybook to add Vue compatibility but it uses iframes to wrap the root. vue play uses iframes as well so the devtools only recognize the wrapper application (also built in Vue.) It is also incompatible with tools like jsfiddle.
I think a really cool feature would be to introduce a "context" menu like the one in Chrome Dev Tools:

With this, we could select the context in which we want the Devtools to run. The menu options would include the top level window.document and any iframes it detects one level deeper. When a context is selected, the Devtools will reinitialize. If vue is not discovered within the top-level context, it would default to the first iframe in which it finds a Vue root instance.
@matt-oconnell, hmm, nice idea, easy way would be to access all iframes from same domain name and check for vue there.
I am using an iframe for WYSIWYG purposes, therefore rendering content programatically with Vue.
Here's the deal: when I highlight components inside iframe, they are all shifted:

It seems, that vue tools are taking component coordinates relatively to iframe window, but render relatively to parent window.
This is something I'm working on, the basics features are easy to add but there're some complications as well to think of
Any timetable for this? It makes the tools unusable on a webapp I'm working on.
Ho @posva there is some workaround to enable today the devtools to work inside a workbook projet.
DevTools and Storybook are awesome!
All' the best.
vue-devtools work just fine with vue-play (https://github.com/vue-play/vue-play),
which uses iframes. So, presumably that's not the reason why vue-devtools won't work with storybook/vue.
hey @mgesmundo, no there isn't yet. At the end, I couldn't advance more on this but others are working on it
Hi @posva I found a simple workaround:
<badge/> inside a Badge group: http://localhost:6006/iframe.html?selectedKind=Badge&selectedStory=%3Cbadge%2F%3E)What do you think about adding a button (or a shortcut) to perform this operation?
The workaround above by @mgesmundo is not sufficient in a situation where the framed document must be framed to function properly, e.g. it uses something from window.top. The best solution would probably be something like what @matt-oconnell originally suggested in this issue.
as @tuomassalo said it doesn't always work so adding a button for a workaround that doesn't always work is a bit too much 馃槃 . An md with the instructions to do it could be useful though
+1 To add another use case where this is required - using Vue with any Google App Script development.
Now that google has released the clasp CLI tool (https://github.com/google/clasp) for app script development using vue and components in an app script environment has just got a million times better. However they sandbox all user javascript and as such vue-devtools doesn't work as it can't detect the user code iframe.
So this makes a widespread and popular production environment where vue-devtools could start working with this change.
+1 This also applies to Office 365/office.com addins that are executed in iframes.
I would also find this useful in browsers extensions development. I am using Vue in my browser extension and devtools are not recognizing it.
couldn't wait for the iframe compatibility +1
Another Use case - possibly a new issue? possibly related?
https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
For example, using Vue in a Adobe Photoshop Extension.
Chrome devtools connects as a remote debugger to the photoshop extension which runs an embedded HTML app. Vue devtools however don't start up.
In a conversation with @brian-mann at Cypress, he wrote this:
React dev tools has a hook that enables you to point to the correct window. We use it in our own Cypress tests. Likely Vue has this same thing, but if not, could borrow from the same concept as react dev tools.
Vue isn't finding it because it's looking at window.top which is Cypress -> not your App. Instead you can just use your app itself (or cypress code) to point vue to window.top so that the extension finds it. It may be as simple as window.top.vue = window.vue but I'd have to dig in.
Whatever it is, I don't think you need anything in Cypress core to facilitate this. You have native access to everything in Cypress so you just have to look at how the vue dev tools works and then connect whatever it is from your app to the extension.
Hey so I was able to get the stand alone vue dev tools electron wrapper working in an iframe.
https://www.npmjs.com/package/@vue/devtools
Just install that globally, run it and append the necessary script to the page rendered in the iframe. It's letting me debug it now!
I can confirm that this works with:
Instead of adding this to your index.html you can do the whole thing from inside of Cypress itself (so that its separated out from your app code. For instance... you could automatically do this on every visit or on every page load...
cy.visit('...', {
onBeforeLoad: (win) => {
const script = win.document.createElement('script')
script.src = '...'
win.document.body.appendChild(script)
}
})
// or ...
Cypress.on('window:before:load', (win) => {
// same thing here
})
P.S. I haven't tried it, but with the window:before:load hooks you can tap into your document before it loads and inject javascript or do whatever it is you want. You don't even need to insert the <script> you could just implement exactly what the script itself does.
The @vue/devtools package worked with an Outlook IFrame.
Took me a while to understand the instructions... here's a quick recap:
A workaround for some cases with Cypress: Cypress allows you to click on the pseudo URL bar, and this opens a new tab with that URL (i.e. not in an iframe), and your Vue Dev Tools becomes usable in there. Obviously, if you need to work with the very specific DOM state seen in the running test, this probably won't help you, but if you just need to get at the current Vuex data, this should do the trick.
@posva When can i use this? use vue-devtools in iframe
FYI this might not be necessary anymore since we support remote devtools (https://github.com/vuejs/vue-devtools/blob/dev/packages/shell-electron/README.md)
If feasible, I think an iframe context dropdown inside the Vue browser addon is a much better user experience.
In my case, I have multiple Vue iframes so that means managing multiple port settings, and opening multiple vue-devtools instances. Additionally, you must keep vue-devtools updated manually with npm instead of relying on the browser's plugin system.
Also, vue-devtools has trouble detecting Vuex if the script connecting to it is not inside the root window. So I can only debug state in the top-most Vue instance.
Lastly, vue-devtools of course has to be running before your page loads, or else the script inside the page cannot download. This is a minor annoyance but I just wanted to point it out as another downside from a user perspective.
Vue-devtools is great for hard-to-reach contexts outside of a normal browser window, but I think if technically feasible, the context switcher in the addon is a big plus and removes some headaches from specific scenarios.
The context switcher would be immensely useful for me and my team.
I have described the solution of @gabaum10 in on stackoverflow: https://stackoverflow.com/a/59823141/79485
Ran into this the other day - we've been trying to make the developer experience building extensions in our LOS (Loan Origination System) better, so our teams can work more efficiently. The way the (vendor) system works, is we build our Vue apps in our IDE, run the build and copy and paste the minified output into the system - it inserts the code into the DB and then anytime that "script" is called from the UI, it loads the JavaScript from the DB and dumps it into an iFrame with inlined script tags. Weird, I know.
The DX on this is terrible, it's a bunch of:
Well, the vendor released a new feature, where we can use external JS files, which turns out, also works with local files, so I can run Vue in development and see the app running in the system. This gets rid of all of the above steps and makes it so we can actually build these apps like a real Vue app should be... except for the fact that I can't use Vue DevTools, because the LOS injects the JS into an iFrame ;'(
As it stands, the new solution is a huge upgrade to what we've been doing previously, but being able to use the Vue DevTools would be a HUGE win, as well. I was hoping that figuring out how to proxy to the localhost instance, or adding the development build would allow this, but the iFrame seems to be the limitation.
I might play around with @suterma 's solution and see if I can get it working for us in the meantime by just injecting that localhost script into the iFrame on load. It's definitely not ideal, but it's a start. The unfortunate part for us is that, the system takes the current state of the local script and injects it into the iFrame, so Hot Module Reloading doesn't work. Still, we're pretty excited that with a few workarounds we don't have to resort to a bunch of dumb hacks.
This is an issue for all methods of using Vue Devtools. I created a write up + reproduction for Vue 2.x, Vue 3.x, and Vue External devtools.
Main repo
https://github.com/JessicaSachs/vue-iframe-devtool-issue
Branches
Should we split out this issue into the version-specific bugs? IIRC the 3.x devtools are a major rewrite.
Most helpful comment
Any timetable for this? It makes the tools unusable on a webapp I'm working on.