Can 1password not pollute the DOM with data attributes?

cjke

I have noticed recently that 1password is polluting the DOM with data attributes such as:

data-com.agilebits.onepassword.user-edited

As a dev, it's quite annoying when trying to debug one thing or another and the expected dom doesn't match what is present, esp for dynamically constructed pages/sites/apps (for example, pretty apparent when using React).

Cheers,

Chris

---

1Password Version: 6.3.5
Extension Version: 4.6.1.90
OS Version: OSX10.12.1
Sync Type: Not Provided
Referrer: kb:undefined, kb-search:user-editted, kb:undefined, kb-search:user-edited

jxpx777

Thanks for the feedback, @cjke. Right now, data- attributes are the best way we've found to reliably track bits of data about parts of the page. We'll keep an eye out for better alternatives, and if we find one, you can be sure we'll use it instead. I'm sorry for the inconvenience in the meantime. One thing you could try is having a specific Developer profile where 1Password is not installed so that you can inspect your React views without additional clutter.

--
Jamie Phelps
Code Wrangler @ AgileBits

cjke

Hi Jamie. Thanks for the reply.

The later solution isn't really a great option in my particular case - I'm using 1password to manage test accounts to quickly log in and out of applications I am working on - jimmy@example.com + password kind of situations. I'm also using it to prefill test data, one of the reasons why I purchased it.

Obviously I don't know your codebase, and everyone just loves people with "ideas" - but, for example, jQuerys data related methods don't need to manipulate the DOM to store data about an element. I believe they have a element reference map.

Am I incorrect in saying this is quite new?

jxpx777

Thanks for your gracious reply, @cjke. We used to track some of this stuff differently. It's been some time since that change, but if I recall correctly there were some cross-browser bugs with tracking fields in this way and the performance was pretty bad, mostly because objects can't be used as keys for Objects so it meant having a different data structure that would then need to be searched each time. If the page is well coded and all the fields have good, unique id's, those can be used of course, but there are a great many sites that either do not provide id's for fields or have non-unique id's. jQuery's approach, which you described pretty well it seems, is interesting. We would need to investigate this idea thoroughly to make sure it works across all the browsers and in the Javascript sandboxes that extension scripts execute in, so I don't want to promise anything right now.

Thanks again for the feedback!

cjke

Ok thanks Jamie. Cheers

jxpx777

My pleasure! Let us know if you have any other questions or concerns.