I have a user testing some new features, which include the Browser element's write to clipboard function. This feature working on iOS devices (iPhone, iPad) with Safari is especially important, but it doesn't appear to be working.
There was a bug reported by @sid back in late 2021 that didn't seem to be resolved. However, I'm not calling write to clipboard on page load like in the bug report, there is a form and button used to call the API, then on success, call the browser's write to clipboard.
This passed with flying colors using all versions of Chrome on all OS's so we know the function is working.
A thread here discusses the issue and provides some solutions. Is this still an open bug in Wappler?
The resolution was the workardound, as mentioned in the thread - because of Safari limitations, and not Wappler.
And last I checked in some 6.x release, it was still working.
This is exactly what is mentioned in the thread. Safari does not allow copying on events, without any user interaction.
The workaround I had implemented was to show the output in a textbox, and button to copy besides it. So when the user would click on "COPY" button, it would open another UI with text in an input and another copy button besides that - which works.
From what I recollect, copying has started working on Safari lately, without the workaround. But as you have reported, maybe not.
In the thread I linked to, it gave advice about the order of using 'await' and 'ClipboardItem'...
It's because of your await call before calling clipboard.write . Apple doesn't allow this. You have to pass your promise directly into ClipboardItem
I have poked around inside the lib/ folder of my project, but in the time I was able to dedicate looking into this, I could not find the JS for Wappler's 'write to clipboard' to see if the order matched the advice.
My implementation requires a user's input, but makes the call to 'write to clipboard' on success, rather than directly from the submit button. Testing shows this to work successfully on MacOS, but not iOS devices running Safari.
Forgot to get back to you.
Tested just now on Safari 18.0, and clipboard function does work.
I have the value in a variable, and on click of a button, I just do browser1.writeTextToClipboard(varScript.value).
It appears my approach is what iOS is trying to prevent from happening. On button click, I call a server connect API script, which gets/returns the data, then on success, I call the browser1.writeTextToClipboard(). It's this second step that iOS doesn't allow because it's not a direct result of a button click tied to writeTextToClipboard. It's the direct result of an on:success event which iOS sees as an unauthorized method to writing to the user's clipboard. This is how I'm understanding things.
My new approach will be to call the API on page load, and pass a keyed array back to a client-side variable. I'm hoping I can loop through the keyed array on button click and have writeTextToClipboard() work, otherwise I'll have to loop through the keyed array on page load, populating 7 different client-side variables so that on button click, all that happens is a call to writeTextToClipboard().
Just completed the development. It's being tested now. Didn't end up using a keyed array, it was much easier to use GROUP_CONCAT in my query which became the dynamic value of each button. Using .where() to grab the correct GROUP of values for each button.
On click, each button calls writeTextToClipboard(value) which should not offend iOS now.