search

w3c / web-share-target

Web API proposal for receiving shared data
https://w3c.github.io/web-share-target/
Other
191 stars 20 forks source link

Give example with POST and state POST semantics #57

Open mgiuca opened 6 years ago

mgiuca commented 6 years ago

Raised in w3ctag/design-reviews#221.

@slightlyoff: "It would be great to see expanded examples, particularly ones that demonstrate how to deal with files and the POST mechanism from Service Workers. These don't seem to be in either the spec or explainer yet."

We shouldn't have files (since we don't support that yet), but we should give an example of receiving a POST, and non-normatively state the semantics we expect (the usual; that if you're going to perform a side-effect from the HTTP request without any prior user interaction, it should be a POST).

mgiuca commented 5 years ago

This issue has come up in the design of ST, about how to deal with a POST share target and send the data to the newly opened page without roundtripping via the server. It can be done but it's non-trivial and hard to figure out (see Squoosh which handles share targets by a complex dance of waiting for the client to open, then postMessaging to the new client).

The current POST example doesn't really go into that; it just forwards the request to the server. I'd like to make an example (or possibly even a library) that makes it easier to do the above dance.

mgiuca commented 5 years ago

@raymeskhoury

incognico commented 4 years ago

Maybe this is a bit off-topic but consider my use case:

I have a simple PWA which basically is a upload form with an input type file for an image and a description input type text. The idea was to use the share target to directly share an image, preview it in the PWA, let the user add a description and submit the form.

It is all well working until the actual upload part as you can't just add a File object to an input[type=file] for security reasons (the user must intentionally fill it by himself). It is only possible to assign a FileList object. This currently is only returned by DataTransfer which is part of the HTML5 Drag and Drop API. Working around this by creating a bloburl and let the user drop the preview into the input[type=file] to "consent" does not work on mobile because there are no drag, only touch events.

The current workaround is just to replicate the form in the service worker and use xhr to basically POST the exactly same thing I would have either way. Feels kind of stupid to me as the user has already "consent" to use the shared image by manually selecting it and hitting the share intent, this part feels missing to me.

Probably an edge case but there are my 2c.

mgiuca commented 4 years ago

That is a very interesting edge case. Probably just something we haven't thought of: essentially you want to receive a share but not post it to the server right away, but load it up into a web form that can be posted using conventional form posting?

I'd say your workaround is correct (use XHR to post it is the only way to go, if you are intercepting the initial share POST using a service worker).