Various share target bugs |
||||
Issue descriptionRolling these all into one, as I may just be holding it wrong. https://share-target--squoosh.netlify.com/ - This declares itself as a share target for images in its manifest. If a POST request is received, the service worker responds with "Got a post request". Once added to home screen, I expected to be able to share images, "Squoosh" to be an option, and Squoosh to open displaying "Got a post request" Sharing from Google Photos: 1. Share image 2. Select Squoosh. 3. "Share as: Create link, Shared album" I didn't expect the above option to appear, I expected it to take me straight to Squoosh, kinda like it does if I share to WhatsApp. If I select "Create link", a toast appears at the bottom of the page saying "Sharing to Squoosh", but Squoosh never appears. Sharing from Chrome: 1. Naivgate to https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Google_2015_logo.svg/500px-Google_2015_logo.svg.png 2. Long press on image. 3. Share image. Squoosh does not appear in the list. 1. Naivgate to https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Google_2015_logo.svg/500px-Google_2015_logo.svg.png 2. Press share button at bottom of browser. 3. Select Squoosh. Nothing happens. If I repeat the action, I see "Squoosh keeps stopping".
,
Dec 6
Also, it seems hard to test this, as add-to-homescreen from 127.0.0.1 doesn't create a real webapk, so I had to deploy to a public server to test.
,
Dec 6
Here’s a link to the manifest as deployed: https://github.com/GoogleChromeLabs/squoosh/blob/a75310d4c3f716c114a388532a06d34a78eddc23/src/manifest.json
,
Dec 6
jake: I think we're a touch too early as WST with post data isn't yet enabled. Sorry for getting you excited - we really want to try this out so this was an early heads up but we need a bit more time
,
Dec 7
,
Dec 7
Ah, sorry, I misinterpreted the comments in the doc. Let me know when it's good to test.
,
Dec 7
re comment #2: we generally do support localhost URLs (although you may need to use "localhost" as opposed to "127.0.0.1" - I don't remember off-hand). However, we have an known issue (filed as an internal bug) that can cause this sort of thing if you specify a custom port on a localhost URL (http://b/112440826).
,
Dec 10
#7 per https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy, "http://localhost" and "http://127.0.0.1" should be considered secure contexts, as if they had "https://".
,
Dec 13
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jakearchibald@chromium.org
, Dec 6