fm-sys
[Pairdrop] text send dialog prefill doesn't work
Checklist
- [X] I have searched the existing issues for my problem. This is a new ticket, NOT a duplicate or related to another open issue.
- [X] I have updated "Snapdrop for Android" to the latest version. The bug is reproducible on this latest version.
- [X] I have checked, that this is NOT a general Snapdrop bug. It is only related to the Android app, and not reproducible with the website as well.
App version
master
Android version
10
Describe the bug
Text send prefill doesn't work, cause pairdrop uses a modified send text dialog
Steps to reproduce the bug
- Activate floating text selection
- select a text and choose "send with snapdrop"
- -> Text should be prefilled, but it isn't
Stacktrace
No response
Screenshots and additional context
@schlagmichdoch maybe it's possible to rename the pairdrop.net html elements so that the current implementation works for both, snapdrop and pairdrop at the same time.
Sorry for the delay, somehow I’ve overseen this. Ueen had a similar problem with his addon and created a PR request. I closed it though and can only repeat what I said to him:
It took me a while to tidy up the code for PairDrop to follow the HTML style guide: https://google.github.io/styleguide/htmlcssguide.html#id_Attributes
To make it easier to develop I needed to tidy up a lot of code and I don‘t want to rollback just for compatibility. Couldn’t you simply do a try catch to support both identifiers? Alternatively you could append the url via argument to the PairDrop url: https://pairdrop.net/?share-target=text&text=testtext or fire an event that starts the so called PasteMode. The UI then follows AirDrops example to send the marked text via one click. But you mentioned that you want the text to be editable so I would go with a try catch instead.
Alternatively, you could differentiate PairDrop and Snapdrop whenever the instance is changed and look at the html meta tag: <meta name="application-name" content="PairDrop">
Yes sure, can be fixed on our side of course....
However I don't really like the UI of the PasteMode. It doesn't give any hit that content (and which type of content) is selected for sharing. The "Done" seems quite random, not as self-explanatory as it should IMHO.
Therefore I'll probably go with the JS injection approach.
| Pairdrop | How it is implement in Snapdrop for Android currently |
|---|---|
 |
 |
It doesn't give any hit that content (and which type of content)
Not quite true. It does differentiate between text and files and shows the number of files:
I like the idea of using a toast that is persistent though!
"abort" seemed not right to me as you can share the content with multiple receivers once you are in pasteMode (as it is with AirDrop). Therefore I decided for "Done". Maybe similar to your solution I could add a title "Share Text" / "Share Files" and move the "Done" button to the side. Do you have another suggestion?
As with AirDrop, I wanted the share to be executed by clicking only once. Having to approve the (prefilled) text box first, seems counter intuitive to me when I share text via the share-menu.
I could imagine a compromise though: Paste Mode stays as is is but when text is shared it says shared text ✎ and clicking it opens a dialog similar to the send text dialog where the text can be edited first.
What do you think?
It doesn't give any hit that content (and which type of content)
Not quite true. It does differentiate between text and files and shows the number of files
Indeed. However I had totally overlooked this text, doesn't seem prominent enough to me.
"abort" seemed not right to me as you can share the content with multiple receivers once you are in pasteMode (as it is with AirDrop). Therefore I decided for "Done".
In english it is translated with "cancel" currently, another idea would be to use "finish". However "done" is fine as well, just lacking context currently.
Maybe similar to your solution I could add a title "Share Text" / "Share Files" and move the "Done" button to the side. Do you have another suggestion?
Sounds good. Or maybe order them vertically (although this would take some more screen space)
As with AirDrop, I wanted the share to be executed by clicking only once. Having to approve the (prefilled) text box first, seems counter intuitive to me when I share text via the share-menu.
I could imagine a compromise though: Paste Mode stays as is is but when text is shared it says shared text ✎ and clicking it opens a dialog similar to the send text dialog where the text can be edited first.
I think it should be fine even without the edit functionality. I primarily have implemented that way because I had no idea how to do it better.
However I don't really like the UI of the PasteMode. It doesn't give any hit that content (and which type of content) is selected for sharing. The "Done" seems quite random, not as self-explanatory as it should IMHO.
Tbh I did not like it that much either as it didn’t show prominently enough what was being shared and the „Done“ button blocked the button header which could be useful while sharing.
In the new version v1.10.0 I have reworked the now called share mode to resolve this. I have not tested it on your app though so this is a FYI:
The new UI indeed looks pretty cool and is way more prominent. Like it, thanks for the great work!
What are the endpoints for it / how would I trigger these components?
@schlagmichdoch I finally found time to work on integrating the new share UI.
It's working fine for text by triggering 'activate-share-mode' with the share text as param.
However, I don't have an idea how to do the same thing for files. I have a list of local file URIs, but I don't know a way to build JS File objects out of it. Any idea?
I'm not sure whether Pirdrop's service worker is installed when it is used via a WebView but you can try out to use the file share api which is implemented to support file sharing via PWA.
You need to do a POST request to the webview with the form data field allfiles containing the files. In the same way you can do a POST request without the allfiles field and instead set text, title and/or url.
Take a look at the implementation: https://github.com/schlagmichdoch/PairDrop/blob/794e6304fe87b59624b0ae9a432e2107ecdc8b2d/public/service-worker.js#L176-L180
Or you can inject the file via javascript into an input tag as base64 encoded string and call a method that base64 decodes the files and deploys the share event
You can also inject it by reusing the base64 API:
- zip the files
- base64encode the zip archive
- Call
await pairDrop. base64Dialog.processBase64Zip(base64encodedZipFile)(https://github.com/schlagmichdoch/PairDrop/blob/794e6304fe87b59624b0ae9a432e2107ecdc8b2d/public/scripts/ui.js#L2356)
While this works fine for small files, I get an OutOfMemoryException while trying to load a >50MB file as a single base64 string.
The ideal solution for me would be to only send a list of filenames to the pairdrop JS. Then you could show the file-share-preview (without thumbnail) but on selecting the peer, trigger the normal file selector dialog. Instead of showing the file chooser on my side, it is easily possible to directly return the previously selected storage files. As far as I know, this is the only way to implement the PairDrop file-share-preview in a memory efficient way.
How much effort would that be on your side, and would you be willing to provide such an additional API just for the "Snapdrop & PairDrop for Android" app?