You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I have a modal with a copy-to-clipboard functionality, using sindresorhus/copy-text-to-clipboard. This consistently works as long as my modal isn’t wrapped in react-focus-on. With it, copying consistently stops working in Chrome and Firefox. In Safari it continues to work, somehow. I don’t experience this problem at all using the standalone react-focus-lock.
I’m not entirely sure what’s going on, but I think the way copying to clipboard works in some browsers, is that an event (maybe the one proving that a user did indeed interact and that the code should be allowed to manipulate the OS’ clipboard?) propagates all the way up to document?
I’m guessing this is some sort of side effect of stopping event propagation from scroll events in the scroll lock part of this utility, so if it’s possible to pinpoint these events more specifically and leave others alone, that’d probably be an improvement.
The text was updated successfully, but these errors were encountered:
I've checked how copy-text-to-clipboard works, and look like it's not 100% "focus-lock-compatible". Not sure what it works in focus-lock, but not with focus-on - should not work with both. It creates an element at the body level, and selects it - and it shall move focus to that element, and that should trigger the lock.
Probably I would need to play with it a bit. I hope introducing some timeouts into the logic would solve the problem a bit:
So I have a modal with a copy-to-clipboard functionality, using sindresorhus/copy-text-to-clipboard. This consistently works as long as my modal isn’t wrapped in
react-focus-on
. With it, copying consistently stops working in Chrome and Firefox. In Safari it continues to work, somehow. I don’t experience this problem at all using the standalonereact-focus-lock
.I’m not entirely sure what’s going on, but I think the way copying to clipboard works in some browsers, is that an event (maybe the one proving that a user did indeed interact and that the code should be allowed to manipulate the OS’ clipboard?) propagates all the way up to
document
?I’m guessing this is some sort of side effect of stopping event propagation from scroll events in the scroll lock part of this utility, so if it’s possible to pinpoint these events more specifically and leave others alone, that’d probably be an improvement.
The text was updated successfully, but these errors were encountered: