Extension version 4.5.5 is very slow (confirmed on Chrome and Safari)

pawel

I noticed that 1password extension since 4.5.5 interferes with clicks, and it delays them by about 3s on some pages. The culprit is end.min.js but I have no idea why. I confirmed that it’s 1password extension by disabling it — all clicks work instantly then.

---

1Password Version: Not Provided
Extension Version: 4.5.5
OS Version: OS X 10.11.4
Sync Type: Not Provided

jxpx777

Hi, @pawel. This is the first report I've heard about this, so I'm not sure what could be the problem. Can you let us know more about the problem you're seeing? Is it happening on every page or just a few? If it's just a few, could you send along the URLs so we can take a look? Also, is it happening when you click on a particular element or just any general click? For instance, if you see the problem when you're clicking a submit button on a page, is there a delay when clicking into a text field?

pawel

Hello! Unfortunately, I can’t share the page as it’s an internal business intelligence tool. I narrowed down the problem to 1password extension “hijacking” clicks on buttons — that’s when the 4-second delay occurred. I fixed it by explicitly making the buttons non-submit by adding type="button". This seems to make 1password ignore those buttons and remove the delay. If that helps, the buttons trigger actions via ng-click (AngularJS directive).

jxpx777

Interesting, @pawel. Thanks for that information. Can you give me an idea of how many fields are on that page? By default, <button> elements do have a type of submit. This is something we've recently adjusted the extension to account for. We just released version 4.5.6. Can you see if you're still seeing the same behavior in that version?

Thanks!

pawel

There are quite a few fields on that page. A few <input type="text">, some <select>, and a lot of <input type="checkbox">. These are inside custom multi-select drop-downs so there can be tens or hundreds of them on the page. Might that be the reason? Is 1password going through all of them to see if any are username/password fields? In that case, maybe the solution would be to ignore checkbox fields (if they’re not ignored already).

jxpx777

In the latest versions of the extension, we have expanded 1Password's ability to check certain attributes during autosave. The main thing is that we look for any text fields that might be set up to change to password fields when the user focuses on the element. This should only happen if the text field matches certain characteristics like a name or id that indicates it might really be a password field, but perhaps there is some improvement we can make. It's really hard to say without being able to see the markup. What I can say is that we tested a page with something like 1,000 text fields to see how it would impact performance and it was negligible. Of course, if the page itself has event listeners on those fields that may do some complex work as a result, I could certainly see where it could get a bit bogged down. Again, without being able to test the page out, it's really hard to say what might be the cause.

pawel

Sadly, the newest version (4.5.8.90) is causing problems again. Any idea what changed in this new version that could cause slowness?

I can see in the profile that the f function in end.min.js takes 10s to complete.

jxpx777

Sorry to hear this is still causing issues, @pawel. I'm trying to think of what else could be causing this. I don't doubt your ability to read the Developer Tools, but I have a very hard time seeing how any of the f functions in our script could be so delayed. It does sound like autosave is somehow getting involved because we do have a click handler that checks every click to see if the target should be considered an attempt to submit the form. This is a little tricky though as sometimes the clue to this is not on the actual event target and is instead a few parent elements up. We've even made some improvements in how we search for these kinds of things recently though, so I'm not sure if we may have messed up in that process or if this problem is stronger even than the improvements we made. I'm really sorry I don't have more to offer you right now. I'd love to solve this, but all I can offer is theory and backstory and what-should-happen unless I have an actual DOM I can work with. :( Would it be possible to send us a Web Archive file of that page from Safari so we can at least see what the markup looks like and where things might be going amiss?