Chrome extension - huge delay after "Enter" keydown on page with lots of input elements

geordieh

Hi there,

I don't really experience this a lot personally during regular browsing, but I work on a CMS where our layout engine will open dialogs etc. while users are editing the page, and sometimes these can contain widgets that use a lot of inputs, such as a "folder tree" with checkboxes for each item.

We usually allow these dialogs to be closed using Enter or Cmd + Enter, and I noticed there was a quite a large delay when closing dialogs like this (as opposed to clicking a close button).

Chrome Dev Tools revealed a lot of time was spent in the 1Password extension (screenshots: http://imgur.com/a/GUPdG) in the keydown listener. Hard to tell exactly what heuristics are used from the minified source, but it seems to be related to the processing of over 600+ input elements, the vast majority of which are checkboxes or file upload fields.

1Password doesn't actually throw up a "Save new login" prompt or anything, so it does manage to correctly detect that this isn't a login form etc., but surely there's some way to optimise that detection further, particularly when there's a large set of (likely irrelevant) elements. Giving sites a way to mark elements as "not relevant" probably isn't possible since it'd allow them to prevent autofill, and I'm assuming you have to listen for keydown instead of just form submits since a lot of sites do custom stuff (checking visibility probably isn't useful for the same reasons, plus it'd be expensive anyway). I'm sure you'd have better ideas than me, but maybe even some cheap initial heuristics that don't rely on heavy regex etc. could be good to cull down the set of elements before doing more in-depth processing.

Happy to discuss further, and thanks for the great product :)

Cheers,
Geordie

---

1Password Version: 6.3 (630032) AgileBits Store
Extension Version: 4.5.6.90
OS Version: 10.11.5 (15F34)
Sync Type: Dropbox

jxpx777

Hi, @geordieh! Thanks for your detailed analysis! The thing you're seeing is related to autosave. (Unfortunately, at this time even disabling autosave will not prevent the extension from doing this processing.) When 1Password sees the user press the return/enter key, it leaps into action to see if it should save on the current page. Out of curiosity, is there a password field on the page when this happens?

If you could send us a link to a demo account for the CMS where we could test it out as well, that would be great. You can email it to support+forum@agilebits.com You should receive an automated reply from our BitBot assistant with a Support ID number. Please post that number here so we can link things up.

--
Jamie Phelps
Code Wrangler @ AgileBits

geordieh

Hey Jamie,

Thanks for the quick response!

I probably won't be able to get you access to the real thing, but will try and create a reduced test case and shoot that through. Will comment here when I'm done :)

Cheers,
Geordie

jxpx777

@Geordieh That sounds good. Also, please do let us know if there is a password field on that page as well as that could help us in determining how to improve performance.

geordieh

@jxpx777 Okay finally got around to making that test case: http://codepen.io/anon/pen/xOVjqe

Have attached a screenshot of my Chrome Dev Tools timeline when pressing Enter in the dialog's input field. You'll probably notice the visual delay in closing, but in the timeline you can definitely see that the autosave handler takes about ~900ms, delaying all other keydown handlers until it's finished. No password fields on the page, just 1000 radio inputs (with no name or value attributes, although ideally you could have these and it not be slow too).

littlebobbytables

Hi @geordieh,

Sorry for the delay in responding and thank you for that test site to highlight what you're referring to. I don't know the code well enough to say but like yourself it seems like there must be some improvements we can make here, something simple like if there isn't a password field present skip the thorough checking. Now that would help with the example and I think that's where Jamie was going with his question about the real page, would a simple rule such as bail early if no password field exists apply equally to the CMS site where you first noticed this? I've created a feature request based on this possibility as it doesn't seem an unreasonable rule of thumb, it's whether or not this would be enough to help with the real pages you're seeing this with.

ref: OPX-1197