Progressive Web App support

I use a lot of web-based services and it’s not always convenient to have all of them as tabs in a web browser. Pinning tabs in Firefox is convenient, but those are lost when restarting Firefox, you’re using multiple browser windows and don’t close the one with the pinned tabs last. So I’d like to run some sites as “standalone” PWA in a dedicated window and added to the GNOME application list. There used to be a Epiphany feature for that but I can’t find it and it too is now running in Flatpak so I don’t see how that would work.

The combination of these 3 things don’t add up:

  1. Our web browsers are soon all running in Flatpak containers. I’m running the latest Firefox beta from Flathub testing and it’s looking pretty good.
  2. Websites are increasingly adding Progressive Web App support. Most major ones already do. Some don’t even offer a mobile/desktop app and have gone PWA-only.
  3. Not every website can and will be offered as a PWA wrapper on Flathub

So what’s the most convenient way to exose PWA’s as standalone web-apps in Silverblue? Does anyone know?

Since you say you use a lot of web-based services, you could probably try one more: Firefox Sync. It keeps my pinned tabs from restart to restart, and it also keeps them synchronized across my multiple hosts.

I’m afraid you seem to have misinterpreted my question. I’m wondering how we can install PWA’s with the browsers running in Flatpak.

For example: I want tot take my Home Assistant web-interface (which has PWA) and add it straight to the GNOME application menu, with it’s logo, so that I can start it in a separate window (preferably without showing the browser controls).

How would I do that?

Off topic: I’m already using FF Sync and that works for pinned tabs except when using multiple windows. Firefox only restores the last closed window on a restart.

1 Like

There’s been a short discussion about supporting PWAs in GNOME. I haven’t managed to attract much interest so far, but I still think that it’s worth pursuing.

At the same time, we’re currently trying to reduce the complexity of the Software app, which implies reducing the different types of apps that are being supported. We might need to think about that.

1 Like

Too bad there isn’t much interest so far! I believe this could be a key part of a strategy to bridge the application availability gap for GNOME-based desktops.

I’m not too disappointed about killing Epiphany’s “Web Applications”. It wasn’t that great. I guess in part this is also because Epiphany isn’t that great, both in features and when it comes to the rendering engine.

A year has passed and it looks like WebKit is in better shape to support PWA’s. Would it be an option to create a base “GNOME PWA” flatpak image containing WebKitGTK and a wrapper that enables showing a single website in a decorated window so that you just need to pass an URL to? Sandboxed PWA’s by design. Then all you need is a .desktop file that launches this flatpak with an argument and to pull the application icons from it’s website. What remains is a user-friendly way to add a PWA. Perhaps using a Firefox extensions, or a separate tool similar to the new Extensions program, or a very small GNOME Software extension?

Another option might be to make that a “platform” package, and then make a template for how to build your own Flatpak on top of it where the unique parts would just be the URL and some config?

1 Like

Pretty much what I was thinking, but your description is more accurate!

Flatpaks are layered images so if there’s a “GNOME Progressive Web Application Platform” image with the WebKit related stuff then each actual PWA can be a very thin layer on top of that. This allows sandboxing, data separation and keeping the engine behind all PWA’s up to date by pointing it to a newer platform image after every major and minor GNOME release. So something like these layers:

  1. Actual PWA (URL, separate local storage, potentially tuned permissions)
  2. GNOME Progressive Web Application Platform (versionless, rebase on the newer GNOME Application Platform version image every six months)
  3. GNOME Application Platform version X.YY

Added benefit could be that it would make things simpler by removing Epiphany (or any browser for that matter) from the equation? Yes you need WebKitGTK for the rendering engine, but you might not need the rest of the browser functionality, right? Only a window with the URL rendered. Just speculating here though, I’m not a GNOME developer so I might be over-simplifying too much…

Though potentially not ideal, this route could also provide an easy packaging and distribution solution for 80% of the use cases. Just create one flatpak manifest template for PWA’s and use it to add the 100 or so most popular online services to Flathub. Leverage its automated CI/CD system and distribution network. No need to change anything to GNOME itself or GNOME Software and you can figure out the remaining 20% later. Like how to make it easy for users to add other PWA’s themselves, like less popular services and on-premise services with PWA support for which you need the non-standard URL.

Does this make any sense?

You can always restore all closed windows in Firefox.
press ALT and got to top menu History -> Recently Closed Windows

Also, there is similar (if I understood you correctly) application on flathub store called Tangram

I know but this still means you’re running PWA websites inside Firefox windows, in stead of as “standalone” apps.

Though this is interesting, it still means all these sites are running “tabbed” in one window. They don’t appear in GNOME’s application menu and you can’t run them in separate windows. So this isn’t really what I’m looking for. I’m looking for a way to “save” and treat a PWA as a first-class desktop application.

So, I tried Epiphany, and made reddit app, does it work for you?
PS: Firefox is available now in stable flatpak

toMeloos already addressed Epiphany above, it seems upstream also understands it’s not enough.

Running Firefox with flatpak is only useful in this context insofar as one could configure it to launch instances each dedicated to a single PWA and with less chrome (typically no address bar or whatever else), and then create application files for GNOME to use in the shell and wherever else. There might be interesting Firefox extensions to consider as building blocks.

You probably need cookie support though, and likely local storage as well? Most PWAs we care about probably would require the user to log in

So, is that a problem to login once?

I’m not sure whether the browser or rendering engine handles cookies and local storage. Seems to me the browser is just a GUI to control the engine, not an augmentation of it. But I could be wrong…

Anyway I guess as @aday(welcome by the way!) indicated whatever the solution, it might not happen any time soon :frowning:

Logging in once is fine. You can’t track logins without cookies though, which likely means using a browser.

I’ve used the nativefier npm package for this purpose. It’s using Electron, which isn’t ideal (not least because every webapp bundles its own Electron instead of sharing it), but it’s better than most of the alternatives short of having a real Gnome workflow for it.

That said, when it comes to webkitgtk-based stuff, the main problem is that Webkit sucks, and has done so more or less since Google stopped contributing to it when they forked it into Blink. Apple hasn’t been interested in maintaining a browser engine properly for almost ten years now, and no amount of client development can fix this fact. In fact, a lot of the stuff that makes Safari tolerable are closed-source patches that aren’t even available to browsers using webkit proper, which means that Epiphany will always be buggier than Safari not matter how well developed it is. (I’ve learned this the hard way debugging websites without MacOS available, thinking a bug with webkit proper (say, in Epiphany) correlates to a bug in Safari - I’ve found this to rarely be the case, despite how awful Safari is, Epiphany and the others will always be worse) With Microsoft dropping its own engine, there’s only really Blink and Gecko left. (Yes, I know Webkit finally implemented service workers, but they really, really had to considering their stranglehold on iOS web rendering. It’s not evidence that Apple actually cares.)

/rant

1 Like

Natifier has the right idea, but indeed it doesn’t sound like a good path from a technical point of view. I’d rather not waste all my system resources on the overhead of 8 instances of Electron.

@evenreven so what’s stopping GNOME from switching from WebKit to Blink or Gecko? Seems like a good idea to let WebKit rest and move on to something better. Is it a license issue?

Absolutely not an expert on this, so I should probably just shut up. But I guess what’s stopping them is that WebKitGTK works, while creating webview implementations for GTK with other browser engines would mean rewriting the entire codebase. And for all I know it might not even be possible. Mozilla changed their entire way of showing web views quite recently, I believe, so in a way the slow development of WebKit might even make it a “safer” choice if you want something that kinda works. I don’t know how feasible it would be to use Blink for this. Qt Webengine (in a lot of KDE apps) uses Blink, so it’s definitely possible. But it’s a lot of work. Some more info here.

Switching browser engines is not a small feat, and resources are limited.

Also historically - and I don’t know to what extent that is still true - mozilla has been indifferent to dismissive towards 3rd parties embedding gecko. That played a large part in the transition to WebKit, see

https://blogs.gnome.org/epiphany/2008/04/01/the-future-of-epiphany/

(according to an earlier blog entry, the WebKit backend was added about a year earlier; before that, epiphany was purely gecko-based)

1 Like