PWA: Share Button Open In Browser Instead of Within PWA

[staticvoidmaine]

• I have read this document: https://miniflux.app/opinionated.html#feature-request

When I install the PWA in Standalone or Fullscreen mode on iOS, I've noticed that the External Link button works how I would expect. It opens up an in-app instance of safari and provides the ability to do things like share the link. Here's an example:

Currently, the Share button on an article acts like an in-app navigation rather than "opening a new tab" which means there are no OS-level controls available to do things like actually share the link. I'm assuming there is analogous behavior on android as well. Here's an example:

Is there any way we could adjust this behavior to have the Share button open a new in-app browser to enable sharing, etc.?

[staticvoidmaine]

In the interest of observing how other platforms handle the Share link currently, I've tested installing Miniflux as a web application through:

• Gnome Web
• Chrome

Gnome Web

When Miniflux is installed via Gnome Web:

• External Link opens your default browser (Firefox in my case)
• Share opens in a new window, but in a PWA container like so:

This is an interesting behavior... It doesn't allow you to copy the URL in any way near as I can tell. This may be due to the browser engine being WebKit.

Chrome

When Miniflux is installed via Chrome:

• External Link opens a tab in an existing or new instance of Chrome (ignores your default browser choice on Linux)
• Share opens a new tab in an existing or new instance of Chrome (also ignores your default browser choice on Linux)

What's interesting is that this seems to work as expected (roughly) via Chrome.

[staticvoidmaine]

Well, I had deleted this comment as I'm not 100% sure that ./well-known/web-app-origin-association is the right mechanism for this issue. Upon further reading, it may be but I'm still not sure. Here's the comment details until I can actually test it out:

It looks like this isn't easily accomplished in Safari simply with HTML as it's already in the right shape - the link opens in a new tab in a regular browser tab on Firefox desktop for instance.

The reason this looks to be going sideways is because of how Safari handles links based on the PWA's scope as defined in the manifest. The problem with the manifest scope setting for this issue is that you can only define it once and there's no ability to specify exclusions as needed for the share link.

Digging further into this, I stumbled upon the following helpful issue:

WICG/pwa-url-handler#29

This issue shows that with a /.well-known/web-app-origin-association file, you are given the opportunity to define a related manifest, its paths, and its excluded paths.

This could provide a mechanism to exclude all /share paths so that they open in Safari.

This seems like it would check all the right boxes for this app as it:

• doesn't introduce or rely on JavaScript
• would benefit all platforms, not just iOS/Safari
• should be a reasonably small/low-impact change

I'm going to dig further into this and see if I can get something working, but in the event anyone associated with the project reads this before I get much further, here's what I could use for feedback/guidance:

• Does seem like the right approach for this project?
• I'm not terribly familiar with Go, so any advice on adding a nested route for serving up this file would be helpful! (.well-known/web-app-origin-association)
• based on this example web-app-origin-association file, there would need to be a mechanism to render in the user's hostname into the manifest field so the manifest can be resolved properly. Would using the BASE_URL environment variable be fine enough?