share_target data reloads my entire PWA even when I try to block the GET or POST request

[blurymind]

Basically I have an app, which lets you write dialogue for games. It's open source, so you are welcome to have a look at what I have so far for it.
https://github.com/YarnSpinnerTool/YarnEditor
It's using webpack, so this is where the manifest is made
https://github.com/YarnSpinnerTool/YarnEditor/blob/master/webpack.config.js#L113
its also injecting some custom service worker logic here
https://github.com/YarnSpinnerTool/YarnEditor/blob/master/webpack.config.js#L171
which lives here
https://github.com/YarnSpinnerTool/YarnEditor/blob/master/src/sw-src.js
Btw the pwa is hosted on
https://yarnspinnertool.github.io/YarnEditor/

so I am kind of forced to put /YarnEditor/ as the action in the manifest,otherwise it navigates it to https://yarnspinnertool.github.io

The app is at a stage now where workbox is caching it, so if you refresh the browser while offline, the app still loads.

I've been struggling with adding the share_target feature - or the ability to send data to the pwa from other apps.

My request here is for a way to prevent the share_target feature from completely obliterating my app's state. I want to have my app receive data and react to it, add to its state (such as sharing text or url populates a text field, but without affecting the active state of the app (opened document, edited data, etc etc).

Currently it can receive data here
https://github.com/YarnSpinnerTool/YarnEditor/blob/master/src/js/classes/app.js#L127
but doing so kind of negates the whole point of the feature- since it reloads the pwa and wipes the user's progress completely. The user is not adding to their existing data, because share_target reloaded the window and lost it.

I couldn't find any meaningful examples that fit my scenario.
Is there ANY way of preventing the share_target feature from reloading the pwa's page (post or get).

Is there an example where we receive data from other apps without reloading ours? It reloads the pwa even if you give it a fake url. The data is received, but it triggers a reload that wipes the app's state.

How do we deal with that? Do we cache the app's state and load it after share_target reloads the app? Or is there a way to prevent the reload from happening in the first place and just receive the data?

Can the current spec allow receiving data without reloading the pwa, and if so how do we do that?

I post here, because the workbox devs couldn't find a workaround solution to this and pointed me to this issue tracker. You can read my discussion with them and things we tried so far to get around it here
GoogleChrome/workbox#2557

[ewilligers]

This is the problem that Launch Events are being designed to solve.

[blurymind]

is there really no working way around this? For example maybe if we could open two windows in the pwa and reload the second window?
Send the post/get to a dummy second window, then dismiss it?

[marcoscaceres]

Closing as out of scope for the spec. Hopefully launch events will address this issue.

[marcoscaceres]

Actually, let me move it to Web Share Target...

[tomayac]

Not sure if it's very helpful, but maybe you can take inspiration from the example app I have built. The relevant code is

• https://github.com/tomayac/fugu-greetings/blob/0efd18da1bcc3dc9e3eafdedb767db1e45ac9ad8/public/serviceworker.js#L61-L74
• https://github.com/tomayac/fugu-greetings/blob/0efd18da1bcc3dc9e3eafdedb767db1e45ac9ad8/public/js/script.mjs#L159-L160
• https://github.com/tomayac/fugu-greetings/blob/0efd18da1bcc3dc9e3eafdedb767db1e45ac9ad8/public/manifest.webmanifest#L20-L30.

But as was pointed out above, there is a proper way on the horizon to make this task less cumbersome.

(Just realized the original question was from 2020, anyway, maybe someone still can use this reply now in 2021.)

[kael]

(Just realized the original question was from 2020, anyway, maybe someone still can use this reply now in 2021.)

Is this code still valid ? I'm trying as well to launch a web share target while a media player is playing in the PWA, but despite intercepting the fetch and returning a Response.redirect('/', 303) in the service worker, the PWA completely reloads and stops the mediaplayer.

I've tried by following your example but can't make it work.

Does this trick still work with Android Chrome 107 ?

[tomayac]

@kael The code is still valid, and launch handler can be tested, albeit at the moment it doesn't work with Web Share Target yet. Do you have your code hosted somewhere so I can take a look?