1Password browser extension is causing inputs to lose focus on the Reedsy editor

alecgibson

I'm a developer working on the book editor section of reedsy.com, which is built on top of Quill. We've had complaints from some users that using the 1Password extension causes some of our inputs to lose focus when typing.

To reproduce:

1. Enable 1Password extension in Chrome (also happens at least in Safari)
2. Sign in to reedsy.com
3. Go to "My Books"
4. Create a new book and open it
5. Type some text into the editor
6. Highlight that text
7. Click the link icon in the popup toolbar
8. Try to type in a URL, but notice that the input loses focus after a single keystroke
9. Disable/uninstall the 1Password extension
10. Reload page
11. Now typing is fine

---

1Password Version: Not Provided
Extension Version: 4.7.3.90
OS Version: macOS 10.13.6 (17G6030)
Sync Type: Not Provided
Referrer: forum-search:focus

littlebobbytables

Hello @alecgibson,

You've given excellent steps to reproduce which really do make all the difference in the world but so far I've been unable to trigger the behaviour you're experiencing. I've tested the stable version of our companion extension (the one at version 4.7.3) and I've tested both Firefox and Chrome in case it seemed to be browser specific. I even tried with 1Password X, our standalone extension as that interacts more with the page than the companion extension. I don't know why but in all my attempts not once did focus shift from the URL field and I was able to continue typing an entire URL.

If we can reproduce I will definitely file a bug but as it stands the inability to recreate the failure means any attempt to modify the code would be a needle in the haystack. If you use Chrome could you see if you continue to see the issue in a completely new Chrome profile, one where only the 1Password extension is installed. If you haven't used Chrome profiles before then Google's support page, Share Chrome with others or add a profile can help with this.

alecgibson

Sorry, I just realised I'm a total idiot - this is only happening on our (private) Staging environment after bumping our version of Quill.

However, I do still think it's a 1Password issue. We're due to deploy next week (hence all the testing this week), so I'll let you know once the change is live and then you can hopefully reproduce the issue.

littlebobbytables

Hi @alecgibson,

Believe me, we've all been there. Trying to keep track of what's in stable, beta or private nightly has resulted in more than once me thinking something was okay but only because I thought some code was identical between builds and being quite wrong.

What surprises me is the companion extension is extremely passive. It is a bit more aggressive when you actually ask 1Password to fill but otherwise it just sits there and shouldn't be doing much until it thinks a form is being submitted. That's in part why I also tested 1Password X because it does add things to the page, being a standalone extension it has to create its entire UI itself while the companion extension doesn't do any UI beyond the toolbar button - everything else is handled by 1Password itself. Very odd indeed. Please do keep us updated!

alecgibson

Hi @littlebobbytables I think it's got something to do with:

• Quill works through a MutationObserver watching a contenteditable
• 1Password appears to modify the DOM with data- attributes (which possibly fires the observer?)

But it's hard to say exactly what's going on without being able to poke around in 1Password's innards. I'll let you know when the change is live. Thanks for your help so far!

AGAlumB

Sounds good. We're here if you need us. :)

littlebobbytables

Hello @alecgibson,

We do use a data attribute. It wasn't always the case but after investigating a particular bug we discovered we couldn't reliably rely on data to persist over the expected lifespan of the injected script. To work around this we moved to using a custom data attribute which did prove to be more resilient. I don't know enough about MutationObservers to know whether it's triggering due to the addition of the data attribute so I couldn't say yes or no with any confidence. The companion extension would only ever add the data attribute to the on focus field so I wonder why that would trigger the odd behaviour.

alecgibson

@littlebobbytables we've deployed the update to our production environment, so you should now be able to follow the above steps. Please let me know if you have any trouble replicating!

littlebobbytables

Hi @alecgibson,

I have now been able to reproduce. I'll tinker with the extension to see if we can at least determine whether it is the custom data attribute that seems to be the issue.

alecgibson

@littlebobbytables that's great to hear - please let me know if there's anything else you need to know from me.

littlebobbytables

Hi @alecgibson,

Will do although I suspect that with your detailed steps and the fact that we can reproduce that we shouldn't need to bother you for any further details.

I can confirm that the data attribute is the cause. If I disable that part of the code I don't see the issue. Now we used the data attribute because we couldn't reliably store data using the more normal methods available in the extension but I'm toying with some changes on the off-chance that whatever caused us to go down that path in the past is maybe no longer true. I don't want to promise anything just yet and if you haven't already it might be worth reporting to Quill as well. I'm not sure why the appearance of the data attribute causes focus to shift away from the field but I'm hoping there is something we can do here to make the extension tread more lightly given the data attribute's presence has shifted from annoying some devs because it's there to actually affecting a page.

alecgibson

@littlebobbytables without digging too deeply, I suspect it's because Parchment (Quill's document model) watches the attributes of all of its children, so changing the attribute in this way causes the MutationObserver to fire, which potentially pulls focus back away from our tooltip and into the main editor. That's all educated speculation, but it's my best guess without digging around further.

I don't know if there's some way of tracking if a node is actively being watched by a MutationObserver, but if there is, then maybe it'd be good to disable 1Password in those cases.

littlebobbytables

Hello @alecgibson,

So my concern with having 1Password ignore input fields in certain cases like this would be that there are other legitimate reasons somebody might be using a MutationObserver but 1Password is now ignoring fields we really don't want it to, I'd much rather replace the use of the data attribute by the extension if at all possible. I was testing something but I've just noticed that testing with the stable version of the extension (to confirm the undesirable behaviour) that I can't trigger the response. Has something changed on the production environment?

alecgibson

Hi @littlebobbytables sorry I forgot to tell you - we were having some (unrelated) issues with the change, so I had to roll it back. I'll try to put together a minimal example for you to play with that's independent of our release cycle.

alecgibson

@littlebobbytables I've put together a minimal example here: https://codepen.io/alecgibson/pen/VOWLWj

Similar, but slightly simpler repro steps:

1. Enable 1Password extension in Chrome
2. Go to the above pen
3. Click the "foo" link in the editor
4. An input box should appear
5. Try to type into the box - you should see the selection gets forced to the start of the input every time you type a character
6. Disable the 1Password extension
7. Refresh the page
8. Typing is now fine

(Note that the example is very rudimentary, so you won't be able to add/remove links or do anything beyond just test this input box)

Sorry for all the confusion, and that I didn't do this sooner. Thanks for your help so far!

littlebobbytables

@alecgibson,

Thank you for writing in and working with us! It's early days yet but I'm feeling a little optimism, hopefully it blossoms into something more tangible that works :smile:

alecgibson

Hello! I was wondering if there has been any progress with this?

ag_michaelc

Hey @alecgibson! I will need to check with @littlebobbytables on this; I'm not sure of the status at the current moment. :smile:

littlebobbytables

Hi @alecgibson,

This ought to be fixed in the current version of the 1Password desktop extension. Are you finding otherwise?

alecgibson

Excellent! Must have been on an old version. Thanks so much for your help!

ag_ana

@alecgibson, on behalf of everyone, you are very welcome!

Have a wonderful day! :)