vueuse
`fallback` option in useClipboard
Clear and concise description of the problem
See https://github.com/vueuse/vueuse/issues/3008#issuecomment-1958762073 and https://github.com/vueuse/vueuse/issues/3695
useClipboard use Clipboard API if possible, but there are chances that:
- The content is served in http like #3695
- The permission API returned by browser is not standard (e.g.: with undefined or prompt, but still always refused to read and write when requesting for security)
Suggested solution
I am thinking whether adding a new option called fallback would be helpful, when this option is set, whenever Clipboard APi fails (user refuse when prompt or browser refused for security), try again using the legacy way.
Alternative
No response
Additional context
No response
Validations
- [X] Follow our Code of Conduct
- [X] Read the Contributing Guidelines.
- [X] Read the docs.
- [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Any news? I've been bit by this jut now. Even a callback would be sufficient so that I could open a popup with a message and the text to be copied displayed.
@tajnymag @Mister-Hope Do you have a minimal reproduction for this issue? Are there any steps to reproduce this without having an in-app browser?
I mentioned two cases, where I already linked one with the former.
My only other pr in timeline is about the other case.
In short, there could be even more cases where the permission way will fall. I think at least adding such an option has no disadvantages.
@OrbisK I believe my problem was tied to needing my app to work both in http and https environments on modern browsers. I don't have any reproduction at hand. I don't take this issue as a bug but rather an improvement that handles a bunch of cases when the library calls could fail and we could notify the user about it or work somehow around it.
If we add a fallback, I need to know when to use the fallback.
whenever Clipboard APi fails (user refuse when prompt or browser refused for security), try again using the legacy way.
Do you mean when NotAllowedError DOMExceptiom on navigator!.clipboard.writeText(value) or what is failing in your case?
If we add a fallback, I need to know when to use the fallback.
whenever Clipboard APi fails (user refuse when prompt or browser refused for security), try again using the legacy way.
Do you mean when
NotAllowedError DOMExceptiomonnavigator!.clipboard.writeText(value)or what is failing in your case?
I'm currently sick, so I can't really do much coding now, but I believe that was it if I'm reading MDN correctly.
I've added the fallback to useClipboard (#4512), maybe you can test it wherever you get this problem. Actually navigator!.clipboard.writeText(value) should never fail with NotAllowed because we are checking for permissions. Please let me know if this solves your problems 😄
(when you are healthy again)
Maybe you can patch it locally before we are releasing this.