DOM nodes not being released when navigating away from forms in Angular SPA
I've been working on an Angular SPA app and I think I have discovered that having the 1Password extension enabled causes DOM nodes to accumulate and not be removed, and secondarily causes memory to increase without release. It happens when navigating to a page with a form, touching a text-input field on the form, and navigating away from that page. It doesn't happen if I simply navigate back and forth between the pages without touching the form's text-input field. When I disable the 1Password extension, the DOM nodes, JS heap, and listeners are all periodically reduced to minimal amounts.
I reported it on the Angular issues forums here: https://github.com/angular/angular/issues/36590, thinking it was an Angular bug initially, but am less sure now that it is. That post includes more detailed description as well as three screen snippets of the DOM node accrual from a performance recording in Chrome.
I'm a long-standing user of 1Password and am a huge fan of both the app and the browser extensions, so I'm hoping you might be able to shed some insight and maybe even offer a remedy or a workaround, or even point out to me something that I may doing wrong or misunderstanding.
Thanks!
1Password Version: 7.4.3
Extension Version: 4.7.5.90
OS Version: macOS 10.15.4
Sync Type: WLAN server
Referrer: forum-search:dom nodes
Comments
-
Hey @seanreed ,
Sorry for the delayed response here, I just couldn't find a clear answer on the issue.Do you have the ability to test things with our 1Password X extension? https://support.1password.com/getting-started-1password-x/
If so, please do let us know how that goes and if the issue still exists when using 1Password X.0 -
@seanreed You can sign up for a free 30 days trial and test it, then remove your payment method and let the trial run its course :chuffed:
https://1password.com/sign-up/0 -
@Yaron I signed up for a free 30 day trial, installed and enabled the 1Password X extension in Chrome, and ran the test again. I am getting the exact same result.
Now I would like to remove my payment method from the trial account, as you suggested, but I see no option for that. Please send instructions for how I can do that.
0 -
Hi @seanreed!
Yaron asked if I could take a look here. We care a lot about performance, so I'm keen to figure this one out.
Occasionally, 1Password has to store data linked to DOM nodes, and we do this using WeakMaps. These allow the garbage collection of their keys. When investigating this, I did spot one instance where we weren't doing that. That's fixed now, and should be in a beta soon. I'll let you know when it's ready for you to take for a spin.
That said, looking specifically at the accumulation of nodes in the test app you shared, I'm seeing the behaviour you described both with and without 1Password X. I saw the same when testing in Chrome 81, 83 and 84.
Could you run a few more tests without 1Password X? If you continue to get the same results, I would love some more detailed steps about how you're testing. To get the number of ndoes in your images, I have to navigate back and forth at least fifty times or so. Is this what you're doing, or do you have a quicker method?
0 -
Hi @oliverdunk .
Thanks for taking the time to investigate this.
It's interesting that you're seeing the behavior both with and without the 1Password extension in Chrome. As soon as I disable the 1Password extension the behavior goes away for me.
I know from my tests that the nodes will accumulate even with the 1Password extension disabled, but they are periodically reduced back down to a consistent number around 60 or 70. You'll get the same drop that you see in my image here, at the same interval, but it looks like everything is cleared up (garbage collected?) correctly when the 1Password extension is disabled: It's a level sawtooth, rather than one with an upward trend like in my image here. You have to click back and forth for quite a while (couple of minutes) to see the periodic reduction of the nodes and see that there is an upward trend with 1Password enabled and no upward trend with it disabled.
How did you test it?
My tests have been done by running the app on localhost using the Angular cli and running
ng serve. I'm not sure what else I can do to test the behavior. I've reduced it to fairly minimal code and tested my sample app in Chrome stable and canary (81 and 84) with the 1Password extension both enabled and disabled (in stable both for desktop and the 1Password X extensions, and in canary only for the desktop companion extension). I disabled everything except the 1Password extension, and then enabled only the 1Password extension. Do you have any other thoughts on what I might be able to try?(I use the desktop extension, btw, not 1Password X.)
I also see the behavior when running the same sample app within Electron. That's where I noticed the behavior initially. My apps were becoming unresponsive after extended use. At first I thought it was an Angular issue, so I removed the app from Electron and ran it on its own. I was able to reduce the code so that it appeared to be related to the empty form field. That's when I reported it on the Angular forums, and was given the suggestion to try disabling any browser extensions, which is how I came upon the connection to 1Password. I've also submitted a report of the behavior to the Electron forums here: https://github.com/electron/electron/issues/23141.
And yes, unfortunately, to get the number of nodes in my images I'm clicking back and forth for a couple of minutes or more, to achieve the same number of clicks that might have originally caused the behavior after extended use in the original app. I think it has to be quite a bit more than 50 in order to see that the reduction is not dropping to the same original 60-70 nodes each time.
0 -
Hi @seanreed,
No problem! Happy to help where I can.
As I think you realised, I'm using the 1Password X extension for my testing. I work on that extension, so if there are issues, I think it would be easier to find them there first. We could then see if it's possible to copy across any changes.
I've tested in two ways. Firstly, I made a small app, which attaches an input element, focuses it, runs the input event, and then removes it. This happens 10,000 times. It was using this that I was able to identify the missing WeakMap. After the behaviour here was what I expected, I ran your app, by cloning the code and serving it locally. I wanted to try and get as close to the testing you were doing as possible. In this case, I saw the behaviour with and without the 1Password X extension.
We've actually just realised 1Password X beta 1.20.1, which contains the WeakMap change. Could you try running that and see if it makes any difference?
If you continue having trouble in that release, let me know. I'll take your demo site for another spin and see if I can get any further.
0 -
Hi @oliverdunk ,
I don't have access to the 1Password X extension since I use the standalone desktop app and sync everything with WLAN from device to device. I don't have a 1Password online account subscription. I signed up for one (see above) to test the 1Password X extension, but I found the exact same results, so I deleted the billing and the account, since I don't need it.
I've just run another test that is slightly different, and I think it's reproducible, if you could check it out with the "1Password extension (desktop app required)" instead of 1Password X (although, as I said, I got the same results using 1Password X). I used my mini sample app on StackBlitz for the test. I tested once with no extensions enabled, and once with only the 1Password extension enabled, and came up with the same results that I did in my original post: the node accretion is only happening with the 1Password extension enabled.
I'm attaching screenshots and a detailed description of the process here. I tested in Google Chrome Version 83.0.4103.61 (Official Build) (64-bit). I'm hoping you are able to recreate what I'm experiencing.
Thanks!
PS: The Angular forum I cite above has closed my original issue there since they don't think it's an Angular bug.
Process:
Go to my sample app on the stackblitz site: https://stackblitz.com/edit/angular-issue-repro2-qr8rx3
Click "Open in New Window"
Open Chrome Developer Tools
Go to "Performance" tab
Click the Record button
Click "Add Item" in form
Enter "test" in the form input field
Click "Home"
Repeat for 150 seconds
Stop performance profile recording
View only "Nodes" in resulting performance overview
All extensions disabled:
Performing the above-described process for 150 seconds with all extensions disabled:
Only 1Password extension enabled:
Performing the same above-described process for 150 seconds with only 1Password extension enabled.
0 -
Hi @seanreed,
I disabled all extensions, made sure I was on the same Chrome version as you, and followed the exact steps you provided. This is what I saw:
I really want to figure this out for you, so I did also have another 'Bit try the same steps. Unfortunately, they could also reproduce the problem with no extensions installed.
I'm not sure what to suggest next. Do you have another computer without our extension where you could try this, maybe?
0 -
Hi @oliverdunk .
So bizarre! I'm having a bit of a difficult time getting my head around this. It would make more sense to me if you found no unexpected behavior in either setting, considering that I'm consistently seeing no unexpected behavior in one of the two settings. I do have another computer I can test this on and will try to get to it today. What platform are you on? I'm on macOS 10.15.5.
0 -
HI @oliverdunk
These are images of the extensions enabled and the nodes on the performance graph using the procedure I outlined above (mini demo app on StackBlitz site, 150 seconds of adding text to form input and returning to home) on a different computer with no 1Password extension. The new computer has never had 1Password installed or enabled, neither the desktop app nor the Chrome extension. It is running macOS 10.15.5, and I tested in Chrome 83.0.4103.97 (Official Build) (64-bit).
Extensions:
Nodes performance graph:
0 -
Next comparison:
Same test using the same StackBlitz-mini-app-150 procedure above on Windows 10 Home 1909 and Chrome 83.0.4103.61. The Windows instance is running as a virtual machine in VirtualBox 6.1.8. Neither the 1Password desktop app nor the 1Password Chrome extension has ever been installed on this machine.
Extensions:
Nodes performance graph:
0 -
A linux comparison:
Same test using the same StackBlitz-mini-app-150 procedure above on Ubuntu 18.04.04 and Chrome 83.0.4103.97. The Ubuntu instance is running as a virtual machine in VirtualBox 6.1.8. Neither the 1Password desktop app nor the 1Password Chrome extension has ever been installed on this machine.
Extensions:
Nodes performance graph:
0 -
@oliverdunk BTW: Not trying to overwhelm you with all this! Just trying to add as much relevant info as possible to narrow down the potential source of the issue. If it's something I'm overlooking, or if there's something you can recommend to work around the issue, definitely let me know!
0 -
@seanreed, no problem at all. I really appreciate you taking the time to give us as much information as you can.
Still taking a look on our end, thanks your patience.
0 -
Hey again, @seanreed 👋🏽
Would you be able to send an email to support@1password.com? I think it would be great to have somewhere to chat other than the forums.
Feel free to mention me! I'll look out for your email :)
0 -
Hi @oliverdunk . No problem. I'll do that now.
0 -
:+1: :)
0
