🚔 List of PWA Bugs and workarounds
This is a general repo for PWA bugs in all browsers, likely most of them will be about iOS (Web.app)
In some browsers with Android WebView, e.g. Opera Mini or UC Browser (Mini?), browser sends different User Agent strings for different request.
To be precise, when ServiceWorker is used and in
'fetch'listener you do
e.respondWith(fetch(e.request))for navigation requests, it send original WebView User Agent. But for all subsequent requests, it send custom User Agent which was set by the browser's code.
Doing or not doing
e.respondWith(fetch(e.request))for non-navigation requests doesn't change anything. The only solution is to stop handling navigation requests in ServiceWorker (or
'fetch'event at all).
tag cause Firefox to open Custom Tab browser
Bug Report: https://bugzilla.mozilla.org/show_bug.cgi?id=1515789
Status: Fix will be shipped in FF67
Cross-origin redirects for
tag cause Firefox to open Custom Tab browser, just like if Cross Origin navigation happen.
So for example if you have bunch of images request this way on a page, e.g. 100 image, Firefox will open 100 Custom Tabs for your PWA.
Web App Manfest and ServiceWorker API are supported on iOS since 11.3.
WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=190269
This bug makes Cache Storage persist only until user closes Safari (or it's unloaded from memory). Basically, the cache is some temporary place and is erased when Safari is closed. There is really no workaround around this. It causes this situation.
It also affects websites in standalone mode. This bug also prevents Safari from sharing the cache between standalone mode and normal Safari mode.
Problem is in all iOS version.
At the time of writing (iOS 12.0.1), there is only couple version of Safari where the workaround works.
The workaround is to transfer a session through Cache Storage API, which has shared cache in some Safari versions.
Approximately how the workaround works:
destination='manifeset'request to the server
It works only in iOS 11.4.1 though. It's broken in iOS 12 and iOS 12.0.1, but supposed to be fixed in the next version. WebKit Bug for iOS 12: https://bugs.webkit.org/show_bug.cgi?id=190269
Even though ServiceWorker was introduces in iOS 11.3, it's unknown if anything prior 11.4.1 can support this. It either just doesn't work in iOS Emulator at all or doesn't work prioer 11.4.1 (latest 11 emulator version is 11.4.0).
Tested on real devices with these versions: - 11.4.1 -- works - 12.0.0 -- doesn't work - 12.0.1 -- doesn't work
This issue happens since 11.3 when Web App Manifest is used.
scopeproperty in Web App Manifest to determine which URLs allowed to be opened in standalone mode and which are not. When user website navigates to any URL outside of the scope (this includes any URL with different domain) -- it drops the navigation from standalone mode and opens it in Safari. This makes cross-domain authorization impossible.
Use the iframe.
Let's suppose there is a foo.com website and its login is on login.foo.com
Here is approximately how this can be solved:
basic, the send the response to original authorization from the step 1
opaqueredirect, repeat the steps from step 3
(like there is no manifest at all)
Safari fetches the manifest only when user is about to add the website to homescreen. To be preceice, manifest is fetched exactly when Share Popup is opened.
So if user performs all the steps very fast: 1) Open popup; 2) Tap "Add to Home Screen"; 3) Tap "Add" on the adding popup; Then in some cases the manifest might be fetched yet, so website will be added like there is no manifest.
Thankfully, when Safari fetches the manifest, that request goes to the ServiceWorker with
manifest, as per spec. This means that it's possible to intercept such request and return manifest contents from the cache. So the solution would be to precache the manifest on ServiceWorker
installand serve it to the browser from the cache.
Even if all correct splashscreen elements are added to the page, after adding the website to the home screen, it may not have the splashscreen.
When website is added only with Web App Manifest, Safari doesn't not take splashscreen elements into the account. The solution would be addingelement to the page alongside with the manifest.
Note: It might be better adding
apple-mobile-web-app-capabledynamically and only when in browser mode. When in standalone mode, it may affects URLs behavior since Web App Manifest installed PWA and
apple-mobile-web-app-capableinstalled PWA have different URL behavior on iOS.
If update of a ServiceWorker happens when there is a page navigation in-flight and ServiceWorker
installevent resolves sooner than the navigation page is finished loading, then Safari kills old ServiceWorker immediately even without calling
self.skipWaiting()and that break loading on the page and hence it never loads.
Check for navigation requests when
installevent happens and do not resolve the promise if there are any. When page loads, send message to the installing ServiceWorker that it may try again to resolve the installation promise (check again for navigation request, repeat all the steps until no navigation requests, then resolve the promise).
Both Push subscription (Push API) and displaying notifications (Notifications API) are not supported in iOS. There is no pushManager in ServiceWorker registration object - so don't forget to do a feature detection in your code.
There is no good workaround/polyfill as this feature fully depends on the 3rd party Messaging Service infrastructure (Apple Push Notifications Service in that case) which is not supporting the standartized (VAPID, Push API, Notifications API) way to subscribe for/receive/display notifications. There are no signals from Apple/Safari about this feature is under consideration/development. There is a Twitter thread with discussing the possible solution to have a kind of notifications on iOS: https://twitter.com/webmaxru/status/1034882612978966528. Some outcomes: - For Safari on Mac you can set up Push notifications using a proprietary implementation: https://developer.apple.com/notifications/safari-push-notifications/ - The working (but cumbersome) solution is to wrap your PWA app into a native iOS one using, for example, Cordova. - The closest (but still not a "real") pure web solution is to set up a PassBook that can receive push. But this way your notifications are disconnected from the app itself.
When migrating to another Android device all native apps are moved to the new one but none of the PWAs. On the new device for the PWAs there where just empty icons and if clicked on them you could search for the PWA in the Play Store :( Even the top PWAs like Twitter Lite have this problem.