After 2 minutes, it unloads itself

[thany]

Vue devtools version

6.4.5

Link to minimal reproduction

N/A

Steps to reproduce & screenshots

Sorry, no reproduction. I don't know what causes the problem, so I have no way of knowing how to make a reproduction.

1. Go to a Vue2 website in Firefox
2. Open the devtools
3. Wait a few minutes
4. Maybe you have to do some random stuff in the devtools

What is expected?

Nothing happens. Devtools stays open, and stays functional.

What is actually happening?

One of two things may happen:

1. The devtools unloads itself, showing just its logo.
2. The devtools reloads itself, undoing any changes and closing the tree.

In either case, should I have been debugging, making changes, etc, I can just go and start all over. Any work that I'm doing in the devtools is rudely interrupted and goes poof, i.e. it doesn't remember any changes and doesn't recover them.

System Info

System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 10.41 GB / 31.76 GB
  Binaries:
    Node: 16.18.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 106.0.5249.119
    Edge: Spartan (44.19041.1266.0), Chromium (106.0.1370.52)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    vue: ^2.6.14 => 2.6.14

I don't know why so many people use this script, it's poop. Firefox is not in there.

Any additional comments?

Worked fine in some older version. Don't know which one, since browser addons update fully automatically.

[vue-bot]

Hello, thank you for taking time filling this issue!

However, we kindly ask you to use our Issue Helper when creating new issues, in order to ensure every issue provides the necessary information for us to investigate. This explains why your issue has been automatically closed by me (your robot friend!).

I hope to see your helper-created issue very soon!

[ThaDaVos]

I am running into the same issue, but with Vue 3 apps instead - it seems the reconnection logic (I read about it somewhere) may be the cause - the thing is, it's really annoying as I cannot simply restart the extension - re-opening the browser devtools fixes it though

[ThaDaVos]

Hello, thank you for taking time filling this issue!

However, we kindly ask you to use our Issue Helper when creating new issues, in order to ensure every issue provides the necessary information for us to investigate. This explains why your issue has been automatically closed by me (your robot friend!).

I hope to see your helper-created issue very soon!

Sadly they can't - as the Issue Helper is missing vue-devtools ;)

[yi0n]

I can confirm this on Linux with Firefox.

[golgote]

Same issue with Firefox Developer Edition v107.0b5 (64 bits) on OSX (Monterey but saw the same problem on BigSur) with vue 2.7.13 and devtools 6.4.5

[Billybob]

Confirm this on Arch Linux with Firefox

[denisgruba]

Same issue with Firefox Developer Edition v107.0b5 (64 bits) on OSX (Monterey but saw the same problem on BigSur) with vue 2.7.13 and devtools 6.4.5

+1 on the same config, except vue 2.6

[dmke]

I tried to debug this, by inspecting the extension while it un-/reloads. Navigating to about:debugging#/runtime/this-firefox → Extensions → Vue.js devtools → Inspect, and monitoring the console yielded the following warning message:

:warning: Background event page was not terminated on idle because a DevTools toolbox is attached to the extension.

The extension itself then did not unload/reload.

I'm guessing Firefox tries to unload the background page (because it determined it was idle), which triggered a reload of the extension.

Not sure how to proceed from here, as I'm not experienced in extension authoring.

Edit, forgot to mention: Firefox 106.0.2, Vue.js devtools 6.4.5, Debian Linux stable/11.5

[ThaDaVos]

I noticed, as I am currently debugging performance issues, that if I disable all layers on the timeline tab - it will stay working for longer - but that may also be as I keep interacting with it longer (or the timeline page is more active)

[Androphin]

Isn't it possible to disable the time grid anymore?

[thany]

How is this being solved in the React devtools? I'm guessing the two must've been set up similarly, so perhaps the solution is quite similar as well.

[thany]

Can we please get some prioity behind this issue? It's still a problem and it's really annoying to have an invisible timer that counts down to the devtools unloading itself.

It's not possible to downgrade a browser addon. Due to the severety/impact of this bug, I propose someone does one of two things:

• Publish an earlier version, like sort of right now.
• Fix this bug within a reasonable amount of time, which sort of already expired, afaic.

Please let us know which it's going to be, dear devs.

[Locheed]

Yep. This really bugs me. I have to use Chrome when I need to use Vue devtools. Unusable with a FF. There was another ticket before this with same issue: https://github.com/vuejs/devtools/issues/1950

[Billybob]

Seems to work! Arch Linux, Firefox =106.0.3, Vue 2.6.14, devtools 6.4.5

[lhapaipai]

Unfortunately I still encounter the problem, with

• Manjaro Linux
• Firefox 107.0b6
• Vue 3.2.37
• devtools 6.4.5

impossible to work properly with such a problem. current solution downgrade to firefox 105

[pyrsmk]

Same issue on MacOS.

[matthewhutchings]

also having this issue

[craigrileyuk]

Same: Firefox 106 on MacOS Ventura with devtools 6.4.5

[cmauf]

same here: Firefox 106.0.4 on Manjaro 5.15.76, Devtools 6.4.5

For me it's like 15 secs before the devtools die

[pisandelli]

Same here... Linux Pop_OS Firefox: 106.0.3 (64-bit)

Is very annoying... I need to reload the page every 15sec.

[cyberlyght]

Same problem. After a short amount of time the Vue devtools tab goes blank and only shows <\> Sometimes it comes back on. It seemed to start happening in October. Windows 11 Pro 22H2 Firefox 106.0.5 (64-bit) Vue.js devtools 6.4.5 Vue 2.6.12

[Acartuerk]

Can confirm this as well with: Windows 10 Enterprise, 21H2 Firefox 106.0.5 Node 18.9.0. Vue 3.2.41 Vue.js devtools 6.4.5

[tylerFretz]

Yep same problem. Windows 11 Home Firefox 106.0.5 Vue 2.6.14 Vue.js devtools 6.4.5

[uclnj]

Same issue now. Firefox 106.05 Winblows 10 Pro Vue 2.6.12 Devtools 6.4.5

To add, occasionally, Firefox freezes when hovering over components (highlighting in green in the browser) and the tab instance skyrockets to 4.1GB of RAM then suddenly drops to 300MB where it normally hovers. It is constantly loading/unloading to the point I've had to break down and use ... Edge, to debug development.

Edge..I've demeaned myself to using Edge to keep using Vue Devtools.

Update - still doing it after upgrading to FF 107 just now.

[matt-smarsh]

Same issue for me as well. After a period of time (30s to a minute) the Vue tab of Inspector reboots itself, and then another period after that it crashes and doesn't come back.

System:
  OS: Windows 10 10.0.19044
  CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
  Memory: 5.98 GB / 15.75 GB
Binaries:
  Node: 16.18.0 - C:\Program Files\nodejs\node.EXE
  npm: 9.1.1 - C:\Program Files\nodejs\npm.CMD
Browsers:
  Firefox: 107.0
npmPackages:
  vue: v2-latest => 2.7.10

[matt-smarsh]

From @dmke:

I tried to debug this, by inspecting the extension while it un-/reloads. Navigating to about:debugging#/runtime/this-firefox → Extensions → Vue.js devtools → Inspect, and monitoring the console yielded the following warning message:

⚠️ Background event page was not terminated on idle because a DevTools toolbox is attached to the extension.

The extension itself then did not unload/reload.

I'm guessing Firefox tries to unload the background page (because it determined it was idle), which triggered a reload of the extension.

Not sure how to proceed from here, as I'm not experienced in extension authoring.

Edit, forgot to mention: Firefox 106.0.2, Vue.js devtools 6.4.5, Debian Linux stable/11.5

I wonder if the problem is the background tab unloading, perhaps just changing this persistent key from false to true would fix that? What other side effects would be caused by changing this though? I've never made a Firefox extension to know though...

https://github.com/vuejs/devtools/blob/main/packages/shell-chrome/manifest.json#L31

[dmke]

I wonder if the problem is the background tab unloading, perhaps just changing this persistent key from false to true would fix that? What other side effects would be caused by changing this though? I've never made a Firefox extension to know though...

https://github.com/vuejs/devtools/blob/main/packages/shell-chrome/manifest.json#L31

MDN says to manifest.json#/background (emphasis mine):

The background key can also contain this optional property:

persistent - A Boolean value.

If omitted, this property default to true in Manifest V2 and false in Manifest V3. Setting to true in Manifest V3 results in an error.

Currently, Vue devtools has set "manifest_version": 2, but AFAIK even Mozilla deprecated it in favour of v3 (+ a set of extensions to keep ad blockers working). So even if setting "persistent": true is the solution, will only work for so long...

[Charl13]

I also experience this issue (crashing and rebooting) of the Vue devtools.

• Ubuntu 20.04.4 LTS
• Firefox 106.0.2 (64-bits)
• Vue devtools 6.4.5
• Vue 3.2.41

But besides just crashing and rebooting in my case the Vue devtools slows down the application in an extend where it becomes unusable. When I switch to Chromium 107 it works without issues.

Like @Locheed mentioned in https://github.com/vuejs/devtools/issues/1974#issuecomment-1301869934 there is another (closed) issue where this problem is described. It also states this starts to occur in Firefox 106 because they changed the way Firefox handles extension background pages.

This led me to download Firefox Extended Support Release (ESR) where (for me) the problem doesn't occur.

This is not the solution but a work-around for those who experience this problem and need to deliver their stuff yesterday 😅

Note: The Linux variant is an compressed version of Firefox Extended Support Release (ESR) which doesn't require actual installation.

Note: Since Firefox's downgrade protection it creates a new profile by default. I was able to sync my profile by using the --allow-downgrade flag (as mentioned on the page) and logging in with my Firefox account.

[thany]

Please elevate priority for this bug.

Is anyone actually working on this? If not, please do. It's taking a long time, so if there's any additional information required, please do ask for it, don't wait around.

[thatCodingNoob]

Updated Firefox to 107.0 and it seems to fix it

[uclnj]

On 107.0 and still having the same issue but a new twist is the right click context menu is now filled with empty options not previously seen in 106.

[thany]

Updated Firefox to 107.0 and it seems to fix it

You must be lucky then, because the issue is still very much there.

[thany]

What I just don't understand is why the VueJS team can't bloody rollback to a previous version on addons.mozzila.org. It would've been a perfectly viable workaround WEEKS AGO, but instead they leave us with guesswork, nasty hackery, broken UI, and diminished productivity in general.

ROLL IT BACK TO A PREVIOUS VERSION!

One that still works, and then fix the actual issue.

And I want an explanation on why this issue with BLOCKING PRIORITY, afaic, has been allowed to linger for (at the time of writing this) 23 days more than it needed to.

[pyrsmk]

@thany The team does not owe anything to anyone. It is sad to be in this situation but just be kind. If you want the issue to be resolved ASAP, create a PR to help the team that seem to be overbooked. And as a workaround you clearly can use any other browser out there.

[golgote]

Yes, the team does not owe anything to anyone. If this project is not maintained anymore, just take note of it and use something else. Maybe the firefox extension should be unpublished or a warning should be added somewhere, like "we don't have time to maintain this, so use something else". It's just a matter of people. In every open source projects, there are people who do things, people who use things and sometimes people who complain. Personally, I try to make users of my open source projects happy and avoid breaking their code. I know this is not very common in the javascript community where people break other people work all the time. You just have to deal with it and adapt. Or use something else.

[uclnj]

Tried all the way back to 6.1.4 with the same result. After 30 or so seconds the plugin unloads. Sporadically RAM usage on that tab shoots to 5-6GB RAM and kills FIrefox (107).

Just installed FF developer edition with the same result.

[mrozekma]

@dmke's explanation definitely seems right. Vue devtools reload every 30 seconds for me, but only when the tab is idle, and if I connect regular devtools to the extension itself I get that warning after 30 seconds and Vue devtools doesn't go down.

Unfortunately I can't find much on how to prevent this behavior. It seems different from Firefox's tab unloading that triggers when low on memory, you can watch that on about:unloads and it's not happening in my case.

[uclnj]

@mrozekma confirmed - if I bring up about:debugging, pick Firefox and inspect the Vue.js devtools I get the warning

Background event page was not terminated on idle because a DevTools toolbox is attached to the extension.

And as long as I keep that debugger going the Devtools do not unload/refresh and for now it's usable for work until fully resolved.

[thany]

@pyrsmk

@thany The team does not owe anything to anyone. It is sad to be in this situation but just be kind. If you want the issue to be resolved ASAP, create a PR to help the team that seem to be overbooked. And as a workaround you clearly can use any other browser out there.

Sure, but a bloody rollback of the addon is a five minute job. There cannot be a PR for that, only the team behind this addon can do that. Obviously. So, neglecting to do so is exactly that: neglect. It has nothing to do with being overbooked or whatever. It's just a five minute workaround for the problem, so the devs can fix the actual issue in peace & quiet.

How hard is that, really, to understand?

On top of that, it's a simple matter of prioritisation. This issue affects lots of people, on every Vue website, so an issue like this should be on elevated priority, to say the least. That means, apart from the rollback, that the team shouldn't be working on anything else, at least not any new features, until such problem is fixed. That's what it means for an issue to have blocking/critical priority. At least that's how it works in a professional dev team.

[denisgruba]

Do we actually know the devs are aware of the problem? Very top response is a bot response that the message wasn't submitted properly. It's possible that they use an issue tracker instead of checking this page, and never been made aware of this problem outside of the closed issue #1950. Usually you get some fairly quick responses from the devs on other issues, might be the case this one went under the radar.

[dmke]

Good point. I've asked in their forums.

[thany]

Do we actually know the devs are aware of the problem? Very top response is a bot response that the message wasn't submitted properly. It's possible that they use an issue tracker instead of checking this page, and never been made aware of this problem outside of the closed issue #1950. Usually you get some fairly quick responses from the devs on other issues, might be the case this one went under the radar.

This issue is enough. If they aren't looking at any github issues, they are missing out on a whole bunch of other issues, surely. Plus it doesn't make sense to copy things over using some kind of half-working system to another issue tracker when you've already got a perfectly good one right here.

[uclnj]

After updating FF to 107.0.1 the debugger now shows this on the extension

Reading manifest: Warning processing version_name: An unexpected property was found in the WebExtension manifest.

[Akryum]

Firefox recently broke addons as they changed the behavior of background pages. I guess this is a side-effect of it - it will probably be fixed when we switch the extension to Manifest v3.

[dmke]

@Akryum: Can you estimate how difficult the migration to Manifest v3 is?

Would it be possible to build an interim version, with background.persisted = true (as suggested here: https://github.com/vuejs/devtools/issues/1974#issuecomment-1317783154)? I'll offer myself as beta tester for that :)

[Akryum]

https://github.com/vuejs/devtools/compare/main...manifest-v3

[dmke]

I've followed this guide to test the FF addon: https://devtools.vuejs.org/guide/contributing.html#testing-as-firefox-addon, however the yarn run:firefox task fails with "Unsupported manifest version: 3":

Console output

```console $ web-ext --version 7.4.0 $ web-ext run -s packages/shell-chrome -a dist -i src --verbose [$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js][info] Version: 7.4.0 [$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js][debug] Discovering config files. Set --no-config-discovery to disable [$HOME/.config/yarn/global/node_modules/web-ext/lib/config.js][debug] Discovered config "$HOME/.web-ext-config.js" does not exist or is not readable [$HOME/.config/yarn/global/node_modules/web-ext/lib/config.js][debug] Discovered config "$HOME/code/github.com/vuejs/devtools/web-ext-config.js" does not exist or is not readable [$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js][info] Applying config file: ./package.json [$HOME/.config/yarn/global/node_modules/web-ext/lib/config.js][debug] Loading JS config file: "$HOME/code/github.com/vuejs/devtools/package.json" (resolved to "$HOME/code/github.com/vuejs/devtools/package.json") [$HOME/.config/yarn/global/node_modules/web-ext/lib/config.js][debug] Looking for webExt key inside package.json file [$HOME/.config/yarn/global/node_modules/web-ext/lib/config.js][debug] Config file $HOME/code/github.com/vuejs/devtools/package.json did not define any options. Did you set module.exports = {...}? [$HOME/.config/yarn/global/node_modules/web-ext/lib/cmd/run.js][info] Running web extension from $HOME/code/github.com/vuejs/devtools/packages/shell-chrome [$HOME/.config/yarn/global/node_modules/web-ext/lib/util/manifest.js][debug] Validating manifest at $HOME/code/github.com/vuejs/devtools/packages/shell-chrome/manifest.json [$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/firefox-desktop.js][debug] Creating new Firefox profile [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/index.js][debug] Running Firefox with profile at /tmp/firefox-profileWpFkkf/ [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/index.js][debug] Executing Firefox binary: /usr/bin/firefox [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/index.js][debug] Firefox args: -start-debugger-server 46777 -foreground -no-remote -profile /tmp/firefox-profileWpFkkf/ [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/index.js][info] Use --verbose or --devtools to see logging [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to the remote Firefox debugger [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (0); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (1); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (2); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (3); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (4); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/index.js][debug] Firefox stdout: Started devtools server on 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Retrying Firefox (5); connection error: Error: connect ECONNREFUSED 127.0.0.1:46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connecting to Firefox on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js][debug] Connected to the remote Firefox debugger on port 46777 [$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js][error] WebExtError: installTemporaryAddon: Error: Error: Could not install add-on at '$HOME/code/github.com/vuejs/devtools/packages/shell-chrome': Error: Unsupported manifest version: 3 at RemoteFirefox.installTemporaryAddon (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js:90:13) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async FirefoxDesktopExtensionRunner.startFirefoxInstance (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:218:27) at async FirefoxDesktopExtensionRunner.run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:51:5) at async Promise.all (index 0) at async MultiExtensionRunner.run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/index.js:68:5) at async run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/cmd/run.js:178:3) at async Program.execute (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js:263:7) at async file://$HOME/.config/yarn/global/node_modules/web-ext/bin/web-ext.js:13:1 [$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js][debug] Command executed: run $ echo $? 1 ```

How to proceed from here?

[Akryum]

Did you turn MV3 on in FF? https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

[dmke]

No, but even with both config toggles active, I still get "Unsupported manifest version: 3". When starting web-ext with --firefox-preview, I get another error ("background.service_worker is currently disabled"):

Console output

```console $ web-ext run -s packages/shell-chrome -a dist -i src --firefox-preview Applying config file: ./package.json Running web extension from $HOME/code/github.com/vuejs/devtools/packages/shell-chrome Configuring Firefox preferences for Manifest V3 Setting custom Firefox preferences: { "extensions.manifestV3.enabled": true } Use --verbose or --devtools to see logging WebExtError: installTemporaryAddon: Error: Error: Could not install add-on at '$HOME/code/github.com/vuejs/devtools/packages/shell-chrome': Error: background.service_worker is currently disabled at RemoteFirefox.installTemporaryAddon (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/firefox/remote.js:90:13) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async FirefoxDesktopExtensionRunner.startFirefoxInstance (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:218:27) at async FirefoxDesktopExtensionRunner.run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/firefox-desktop.js:51:5) at async Promise.all (index 0) at async MultiExtensionRunner.run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/extension-runners/index.js:68:5) at async run (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/cmd/run.js:178:3) at async Program.execute (file://$HOME/.config/yarn/global/node_modules/web-ext/lib/program.js:263:7) at async file://$HOME/.config/yarn/global/node_modules/web-ext/bin/web-ext.js:13:1 ```

In about:config, I see devtools.serviceWorkers.testing.enabled = true, and dom.serviceWorkers.enabled = true, but no background.service_worker key.

This is with FF 107.0.1. Do I need the Nightly or Developer edition for this?

[dmke]

In FF 108.0b9 (Developer Edition), I get the same error.

It seems, background.service_worker refers to the entry in manifest.json, which is not yet supported by Firefox (see compat chart). This blog post from 2022/10/31 reads a bit like Mozilla prioritizing "Event Pages" over background service workers.

Btw. I've changed background.persisted to true in the main-branch manifest.json, and the unloading does not occur. I'll prepare a PR.