There’s nothing to actually help it atm, from what I was told in my support ticket is that this is a known issue and is on the todo list but no actually time of when it’ll be fixed. I don’t believe it matters if it’s conditional or display cause the DOM node becomes detached and stays in memory but can’t removed cause it’s referenced by something in the VUE code we have no control over.
Essentially same thing with us the memory slowly builds up over time and crashes the browser. As I said above I don’t think there’s currently a fix for this we can do I’ve tried a range of different things and spent over 20 hours looking into this specific issue and pretty much got no where with it. If you do a snapshot before you do anything then again after you perform some usual user functions, do a heap snapshot and search detached in the snapshot. You should find a bunch of detached nodes and if you check through the references you’ll notice a lot of them have the input as the last html element then it becomes some internal VUE stuff.
You can see my example here, this is a detached button but at the root it’s still referenced to an input
If you have the placeholder advanced option, its the old one.
Strange that you still have the issue, I reproduced locally and the fix seems to remove the leak. Did you republish your website? If you use inputs from component, did you publish a new version of the library?
Thank you for answer @Yaj, I am not familiar with memory leaks either but by the look of it I also have a lot of detached items, that being said they don’t seem to account for much of the retained size except for that HTMLDocument line so I am not sure what to do with that
@aurelie As the app has grown over the last years, I probably have a lot of older inputs, would you have any advice on how to tackle this issue as I see easily how time consuming the whole process could be and I want to make sure we are not missing anything else before replacing inputs or other elements.
I’m still experiencing the same issue. With every page navigation, the RAM usage keeps increasing, even if I spend a long time on pages with minimal content. This is especially noticeable with large forms, where the RAM usage increases very quickly as a result.
My testing page now shows improvements. It does still go “up” a bit, but not as drastically as it did previously. If i opened and closed the input toggle many times, i ended up with double RAM usage. Now it’s more steady it seems.
I created a page in my existing app that has the input fields. You can try it here:
No, I didn’t.
I haven’t properly tested my production app yet, but the test page shows improvements. I had to check if I was using new or old inputs, so I removed and added the basic inputs again. Didn’t notice a difference.
I’m not completely sure what the «new inputs» are, so maybe my project still has them around. But it seems other objects are still creating detached elements on navigation. I saw increase in RAM, although maybe not as aggressively as before? Have to test further.
Thought I’d check how our production app is going and looks like this issue is some what resolved. Our heaped memory goes up a lot slower where I’d say users aren’t crashing anymore, which is the main issue. We do still get about 200-500mb an hour but it used to be about 1gb. Definitely an improvement by weweb here, I’d say our page definitely isn’t the most memory friendly either so what I’m seeing now looks more reasonable.
Hi,
I am still investigating the issue to remove the last memormy leaks, but its not an easy task :).
I am happy to read that my previous fixes helped
When you do your memory check, please be aware that sometimes the retainer is the devtools itself (so debugging is having side effect).
For the input, basically when we made the big update of removing wrapper, we updated the input to be only an input, and we migrate most of the existing one to the new one. But for some usecase we couldnt (when you are using the placeholder advanced). This is why there is a ‘new’ and an ‘old’, which are now two separates code/repo
So should we be migrating all the old inputs to new ones?
Because I’ve got lots of old inputs that have the “advanced placeholder” off, but didn’t get migrated. I have applied classes to them, formula driven text colour and attributes if that’s why?
Its not mandatory to migrate them, its just that i wanted to be sure which code i needed to check.
We did not migrate input with classes because in some case classes were able to activate the advanced placeholder option, and we didn’t want to break anything.
The new component is cleaner in term of structure, but there is no known bug on the old one, so neither hurry or mandatory to migrate
I am aware of the issue of it retaining itself, as that one took me for a loop for awhile. But I’m certain the issue I did have wasn’t happening from this.
We’ve talked to some of our clients that were having crashing issues and have heard that they aren’t having it anymore.
Sorry I couldn’t be more helpful on what inputs we were using I’m still not entirely sure which ones we are using. I’d guess we have a mix of old and new.
