question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Potential memory leak when hiding components early.

See original GitHub issue

Describe the bug

When toggling the visibility of some quasar component’s parent just after/while they are rendered, we see that the memory used by said component is not freed after un-render. This seems to be affecting at least q-menu and q-img and especially when they are rendered under “keep-alive”, but might affect more components/scenarios.

Codepen/jsFiddle/Codesandbox (required or your issue may be closed) Sorry, I’m not sure a live environment is very practical to measure the memory difference as outside factors could make the measurement difficult. I have set up this repository that should be able to show some of the problems, so I hope this would be acceptable: https://github.com/CamilleDrapier/quasar-test

There are multiple branches:

  • with “q-menu”:
    • keep-alive-menu seems to have a memory leak problem
    • v-show-menu, is a variation of the previous one and does not show memory problem as far as I know
  • with “q-img”:
    • keep-alive-img seems to have a memory leak problem
    • v-show-img, is a variation of the previous one and also seems to have a memory leak problem
    • q-img, is a simpler variation of the previous one and also seems to have a memory leak problem. In this case, on Firefox, the memory problem seem to be harder to detect as sometimes a “Cycle Collection” would happen, but on Chrome we can observe a constant increase in the application footprint as we click on “toggle”.

To Reproduce Steps to reproduce the behavior:

  1. Run quasar build; quasar serve -p 8081 dist/spa/
  2. Access http://localhost:8081 with your favorite browser (preferably in private windows mode, so that extensions do not interfere with measurements)
  3. Open the “Developer tools” of your browser on the “memory tab”
  4. Click on the “garbage collector button” (Chrome) or the ‘GC’ button on the about:memory page (Firefox)
  5. Record the initial memory (snapshot)
  6. Click on the “toggle” button 10 times
  7. Click on the “garbage collector button” (Chrome) or the ‘GC’ button on the about:memory page (Firefox)
  8. Record the memory again (snapshot)
  9. (Edit) Repeat steps 6,7,8 again multiple times

Expected behavior The memory used by the application does not increase consistently each cycle of toggling the content on and off.

Screenshots

For example on the keep-alive-menu here is a view of the memory increase for multiple batches of 10 toggles.

Screenshot_20211228_192957

Platform (please complete the following information): Quasar Version: 2.4.2 @quasar/app Version: 3.2.6

Quasar mode:

  • SPA
  • SSR
  • PWA
  • Electron
  • Cordova
  • Capacitor
  • BEX
  • Vite Plugin

Additional Info:

  • Typescript
  • SFC usage with <script setup>
  • Vuex
  • Prettier (eslint)
  • Standard (eslint)

Tested on:

  • SPA
  • SSR
  • PWA
  • Electron
  • Cordova
  • Capacitor
  • BEX

OS: Linux (20.04.2-Ubuntu SMP) Node: v16.13.1 NPM: 8.1.2 Yarn: Browsers: Firefox/Chrome iOS: Android: Electron:

Additional context

While upgrading our application from Quasar1 to Quasar2, we noticed a sizable increase in the memory footprint of some of our pages, especially for one page that displays a list of components: for each component (that is quite complex/deep) we determine after it is rendered (in our application it is on some “intersection event”, but is this app I have simplified this to “mounted” for a similar result memory-wise) if it should be kept visible or not, if not we store its size and set that size to a dummy container and “unshow” the content. This seemed to be working fine in quasar1, but is problematic in the newest version.

If this sort of thing is something we should avoid doing at all in Q2/vue3, is there some documentation that could help us know this? Or is there a better way to achieve this behavior?

Thanks a lot for the work on quasar in general and on the Quasar2 in particular!

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:10 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
rstoenescucommented, Jan 22, 2022

Thank you for the comment above. Hope that the Vue hook will be fixed soon. Would you be so kind to drop a message here when it does, so that others that read this ticket also know?

1reaction
rstoenescucommented, Jan 19, 2022

The “loading” prop is assigned as an attribute to the native rendered image. So if I understood correctly and there’s a memory leak by using it then it means the browser itself is at fault because it does not releases the memory when the native img is removed from DOM. So not sure how any framework can help because it’s not their fault (Quasar or Vue).

In any case, until this is fixed in browser(s), you can use loading="eager".

Read more comments on GitHub >

github_iconTop Results From Across the Web

JavaFX 8 Memory leak when Hiding Stage - Stack Overflow
I have drastically reduced the amount of memory leaked when the stage is hidden by removing the one and only GIF image on...
Read more >
Detached window memory leaks - web.dev
Detached windows are a common type of memory leak that is particularly difficult to find and fix.
Read more >
4 Types of Memory Leaks in JavaScript and How to Get Rid Of ...
The main cause for leaks in garbage collected languages are unwanted references. To understand what unwanted references are, first we need to ...
Read more >
How to fix the React memory leak warning - DEV Community ‍ ‍
Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your...
Read more >
Solving Memory Leaks with React Native - Enquero
Memory leaks are a problem every developer has to face eventually. Even when working with memory-managed languages there are cases where memory can...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found