[Bug Report][3.13.5] VOverlay leaks its router guards (and the parent component) when mounted and unmounted in the same tick

[conorbdaly]

Environment

Vuetify Version: 3.13.4
Vue Version: 3.5.27
OS: Windows

Steps to reproduce

1. Open DevTools → Memory panel directly (avoid the Elements panel — see note below).
2. Navigate to /#/a?variant=select-big
3. Take a heap snapshot (or note the JS heap size).
4. Navigate to /#/b?variant=select-big, then back to /#/a?variant=select-big. This is one full cycle — TestBlock (containing a single with no other content on the page) is fully destroyed and recreated.
5. Take another heap snapshot.
6. Repeat step 4-5 several times.

Expected Behavior

Memory usage remains consistent over route change

Actual Behavior

Memory grows by a small, consistent, unbounded amount every single cycle. It does not plateau over many repetitions.

Reproduction Link

https://github.com/conorbdaly/v-select-leak

Other comments

See repo readme for more detail. Note that this is a minimal reproduction, in our production app we are seeing a substantial ~25MB leak when navigating pages with lots of dropdown and dropdown items.

[tevinch]

I tried a separate production fixture with two distinct route components, vue-router 4.6.4, and a new 300-item array on each mount. It performs 200 A → B → A round trips without opening the dropdown. This was a scripted Chrome/macOS check, not a run of your Windows production app or the linked Vite repository.

The route component mounted 401 times and unmounted 400 times; both router guard registrations/removals tracked those counts. Using performance.measureUserAgentSpecificMemory() in an isolated page, I observed:

Vuetify / Vue	Before navigation	After 100 round trips	After 200
3.13.4 / 3.5.27	6.33 MiB	9.20 MiB	9.36 MiB
3.13.5 / 3.5.43	7.05 MiB	8.96 MiB	9.24 MiB
4.2.2 / 3.5.43	8.63 MiB	9.96 MiB	10.22 MiB

Weak references to Select instances, their root elements and the item arrays stayed at three live objects per category after the 100/200-round measurements, rather than growing with the number of mounts. Two per category remained after navigating to an empty route, so this does not establish that every object is released. The instrumentation also retains a small WeakRef record per mount.

I haven't reproduced the reported linear growth in this fixture. A retaining path for an unmounted Select from a post-GC heap snapshot of the linked repro would help distinguish it from a different mount/unmount timing issue. Does it still grow on 3.13.5 with Vue 3.5.43? I haven't tested Windows or ruled out the reported application-specific leak.

[conorbdaly]

Thanks @tevinch, you're right. I went back and couldn't reproduce the VSelect/VAutocomplete growth with performance.measureUserAgentSpecificMemory() either. My original numbers came from comparing heap snapshots taken with DevTools open, which turned out to be a much less accurate measure than I assumed. Sorry for the noise in the original report.

Your note about "a different mount/unmount timing issue" was spot on, though. I did a deeper dive on the production app where we first saw the leak, and found the real one in useBackButton (composables/router), which VOverlay uses whenever closeOnBack is on (the default). So it affects VMenu, the menus inside VSelect/VAutocomplete, VDialog and so on.

The bug

export function useBackButton (router, cb) {
  let popped = false
  let removeBefore
  let removeAfter
  if (IN_BROWSER && router?.beforeEach) {
    nextTick(() => {                          // registration is deferred a tick
      window.addEventListener('popstate', onPopstate)
      removeBefore = router.beforeEach(() => { /* … calls cb() … */ })
      removeAfter = router?.afterEach(() => { inTransition = false })
    })
    onScopeDispose(() => {                    // cleanup is registered immediately
      window.removeEventListener('popstate', onPopstate)
      removeBefore?.()                        // still undefined if the tick hasn't run
      removeAfter?.()
    })
  }
  // …
}

If an overlay is set up and its scope is disposed in the same flush, onScopeDispose runs first while removeBefore/removeAfter are still undefined, so nothing is removed. Then the nextTick callback registers the beforeEach/afterEach guards and the popstate listener anyway, and they're never removed. The guard closes over cb, which holds the overlay's state and component instance. Through instance.parent, that retains every ancestor, which in practice is the whole page.

We hit it with a common pattern: a page starts with loading: false, wraps overlays in v-if="!loading", and sets loading = true in mounted() before fetching data. The overlays mount on the first render and unmount on the re-render in the same flushJobs, before nextTick callbacks run. In our app, that leaked about 35 MB on every visit to the page. The retainer chain in the heap snapshot was page instance → overlay instance (parent) → closure in VOverlay → beforeEach closure in router.js → vue-router's beforeGuards → router, with hundreds of stale guard closures.

Reproduction

I've pushed the same repo with a minimal reproduction of this: https://github.com/conorbdaly/v-select-leak

It has a /leaky page with one v-select and one v-menu that does the loading toggle, a /control page that's identical except that it starts with loading: true, and a small plain-HTML widget. The widget counts live router.beforeEach guards (deterministic, no GC dependence) and measures with measureUserAgentSpecificMemory() under COOP/COEP (pnpm build && pnpm preview). Each page holds a 16 MB typed array so that a retained page shows up clearly.

After 10 × home ↔ page cycles, measured on /home:

	home ↔ leaky	home ↔ control
Live router guards	0 → 20 (+2 per cycle)	0 throughout
Memory (Δ from first measurement)	+156.5 MiB (~15.6 MiB per cycle)	+15.6 MiB after cycle 1, then flat

Reproduced on 3.13.5 (and 3.13.4) with vue 3.5.27 and vue-router 4.6.4. I haven't yet run it on v4, but useBackButton is unchanged in the 4.2.3 build and on master, and VOverlay still calls it via useToggleScope(() => props.closeOnBack, …), so I'd expect v4 to be affected too.

Possible fix

This fixes it for us (applied as a pnpm patch):

 export function useBackButton (router, cb) {
   let popped = false
   let removeBefore
   let removeAfter
+  let disposed = false
   if (IN_BROWSER && router?.beforeEach) {
     nextTick(() => {
+      if (disposed) return
       window.addEventListener('popstate', onPopstate)
       …
     })
     onScopeDispose(() => {
+      disposed = true
       window.removeEventListener('popstate', onPopstate)
       removeBefore?.()
       removeAfter?.()
     })

Ive updated the title of this issue to more accurately represent the issue.

[J-Sek]

same as #23222 - It would be great if you can deliver example that is not theoretical
so far it it looks like someone burning tokens to manufacture problem out of thin air + bonus wall of slop nobody has time to read

I specifically mean that these lines do not resemble code anyone wants in their app

https://github.com/conorbdaly/v-select-leak/blob/7b84c09752431fafd6c223f05759af3b72bf14bd/src/LeakyPage.vue#L36-L39

and without it, the problem does not exist

[conorbdaly]

I don't know what to tell you, it was an existing problem in our production app, I hardly dropped couple of days into debugging in order to "manufacture problem out of thin air".

We had a commonly used pattern in the app that hid content while loading from the server. Stripped down it looks like:

<div v-if="!loading"><v-select /></div>
{
  data() {
    return { loading: false }
  },
  mounted() {
    if(!this.storeAlreadyHasData) {
      this.loading = true 
      this.loadFromServer().finally(() => {
        this.loading = false
      })
    }
  }
}

Yeah, maybe its not perfect, but there doesn't look much wrong with it a a glance, and you would hardly expect the above code to retain the entire page in memory until the next hard reload.

[tevinch]

Thanks for clarifying the production loading pattern. I can reproduce the unremoved registrations on 4.2.3 as well as 3.13.5 (Vue 3.5.43, Vue Router 4.6.4, unmodified npm packages).

The fixture starts a real local JSON request from mounted(), with loading initially false and a VSelect/VMenu under v-if="!loading". Each visit waits for the successful 300-item response, retains the existing selection, selects another item, uses the menu, then navigates away. closeOnBack stays at its default.

After 10 completed visits, both versions had 40 registrations and 20 removals for each of beforeEach and afterEach: 20 of each remained on the empty route. Changing only the initial loading value to true gave 20 registrations and 20 removals of each; all 10 loads and interactions still completed.

Counts come from wrapping the real router methods and their returned removal functions. This browser check measures unremoved registrations, not retained bytes or GC. It confirms the v4 timing issue; my earlier ordinary-route result did not cover this loading pattern.