Hello
I wondering how PWA works in current version of sailfish os.
Could anyone tried to run that kind of website and save the shortuct to desktop?
I have read also that browser is a litle bit outdated and mabye PWA could run on some android app?
4 Likes
IIRC currently PWAs are only supported by the Chrome Browser so it is not supported by the Sailfish browser.
Sailfish OS supports to add a website shortcut to the app grid but this is just a shortcut to start the whole sailfish browser and load the weppage inside of a new tab.
1 Like
Chrome should be installed from F-Droid or flatpack?
Hey, this is actually related to more topics than this but maybe someone that is in the know picks it up and answers. What is the status or ServiceWorkes API in SailfishOS browser? According to caniuse.com, ESR60 has support for ServiceWorkers behind a flag, so this brings me to another question about the browser, how can we enable / disable feature flags in the browser? Is it even possible on sailfishos-browser in the first place?
Maybe I should just head to github with these questions, but might be good to stir up some conversation here also.
- A2HS ( add to home screen with icon from web manifest )
- Standalone / Full screen mode for an web app that has been “installed”
I’d like to see all these PWA features on SailfishOS Browser as it could narrow down the apps gap & remove the need for android apps. (given companies will produce PWAs in the future as well)
Have you tried enabling dom.serviceWorkers.enabled in about:config? I have no idea if it works or how to test it, but I noticed that there is such a setting.
1 Like
Thanks ! I tried it but I had just made some updates to our PWA application and apparently I bumped too much dependencies as now it was totally broken on Sailfish Browser (globalThis missing and it landed on ESR65 ) 
Although I’m guilty as charged for misusing web apps (well, a webkit wrapper around local html/js files) it’s really not the best way to go.
The web browser as a ‘sandbox’ for something approaching ‘native’ application behaviour is a hack. At best. The more ‘stuff’ that’s pushed into the browser, the less secure, stable and reliable it becomes.
Compensating this by throwing more cycles (aka Mhz) at the problem is misguided. I’m working on a solution to the very problem I introduced with a quick fix (because I like mahjong solitaire) in ‘wrapped web app’. The solution is proper app 
@poetaster that ‘hack’ is a standard nowadays 
Looking at the lack of apps for Sailfish, PWA will be a huge step for users and the community.
1 Like
I’m not sure what standard you mean, but the more things get pushed to assembly, the less they’ll have anything to do with standards like ecmascript. Looking at some of the more commonly used electron apps is just scary. Use element.io on your phone and lose 30% battery coverage. It causes permanent fan usage on anything from a thinkpad x230 to an apple m1 (latter reported by one of my users this week). Compare to gomuks (in go) or even mirage (QT/QML with c++ for libolm) and it’s not even the same ballpark.
I’m not against webapps per se, I maintain one for SFOS, but even if I wanted to distribute via the web, I’d still try to design well enough to build a parallel QML view. QT/QML is much more performant even if QML is not trivial to design with.
Anyway, google’s android is the defacto standard. I guess I’ll just stand out like a sore thumb.
For anyone interested in the actual standards activity: Web Applications Working Group which is still a ways to standard. The defacto standard is google, copying the old WebOS and Firefox OS ideas of yore.
EDIT: Just to note, Electron apps are not pwas. They they are the evil cousin that ships with the run time. Oh, who supplies the run time? I haven’t looked at the commonalities between electron and element.io’s web app. But I’d bet they drift apart significantly. I did look at the webasm code for libolm. Scared the bejeesus out of me.
I don’t know why you mention electron here when we taking about the PWA. Maybe it’s look similar but in PWA You based usully on native system browser that should drain battery the same way like native browser usage.
1 Like
Exactly. Many pwa apps have the same property as electron apps. dependency hell and resource hogs. Even chrome doesn’t change this. That is why I added the edit.
Actual issue tracker occurred to me and I opened an issue on this.
And Matrix users, please try https://hydrogen.element.io/ as a PWA instead of app.element.io which to my knowledge doesn’t support mobile officially.
1 Like
The most important bit, I believe, is the app manifest Web Application Manifest I was thinking of taking some of the Ubuntu touch pwa apps and building a (new) WebView wrapper that just parses / loads a manifest file. But it’s just been sitting at the back of my mind for 6 months.
I’m not sure the browser, is fundemental since Webview shares the plumbing?
Were you aware of @thigg hydrogen wrapper app? @thigg did you manage to get it working in a CORS/CSP compliant way?
yes, but because hydrogen broke the transpilation to older targets I cant update it right now to a current version. But my development builds solved this by serving the files via a tiny http server
Ok, so I should go try out your development version? if only the sdk were’nt striking …
As I couldnt get a current version of hydrogen working last time I tried, there is no should…
But if you want, I updated the wrapper. Put whatever you want to deploy with it into a folder named hydrogen. You could just download the latest release of hydrogen.
My latest goals were to get notifications working, but that didnt work yet.