├── LICENSE
└── README.md


/LICENSE:
--------------------------------------------------------------------------------
 1 | MIT License
 2 | 
 3 | Copyright (c) 2018 PWA POLICE
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | # PWA Bugs
  2 | This is a general repo for PWA bugs in all browsers, likely most of them will be about iOS (Web.app)
  3 | 
  4 | - [Android WebView](#android-webview)
  5 |   * [Problem: different User Agent for different request](#problem-different-user-agent-for-different-request)
  6 | - [Firefox, Android](#firefox-android)
  7 |   * [Problem: Cross-origin redirects for `<img />` tag cause Firefox to open Custom Tab browser](#problem-cross-origin-redirects-for-img--tag-cause-firefox-to-open-custom-tab-browser)
  8 | - [iOS Safari](#ios-safari)
  9 |   * [Problem: in iOS 12 cache in Cache Storage magically disappears](#problem-in-ios-12-cache-in-cache-storage-magically-disappears)
 10 |   * [Problem: Cookie/Login isn't shared between Safari and standalone mode](#problem-cookielogin-isnt-shared-between-safari-and-standalone-mode)
 11 |   * [Problem: Cross domain authorization in standalone mode doesn't work](#problem-cross-domain-authorization-in-standalone-mode-doesnt-work)
 12 |   * [Problem: Sometimes PWA is added in normal mode and not standalone mode](#problem-sometimes-pwa-is-added-in-normal-mode-and-not-standalone-mode)
 13 |   * [Problem: PWA is added without a splashscreen](#problem-pwa-is-added-without-a-splashscreen)
 14 |   * [Problem: Navigation to a website has infinite loading](#problem-navigation-to-a-website-has-infinite-loading)
 15 |   * [Problem: Push Notifications are not supported](#problem-push-notifications-are-not-supported)
 16 | - [Android](#android)
 17 |   * [Problem: No migration on new Android phone](#problem-no-migration-on-new-android-phone)
 18 |   
 19 | ## Android WebView
 20 | 
 21 | ### Problem: different User Agent for different request
 22 | 
 23 | In some browsers with Android WebView, e.g. Opera Mini or UC Browser (Mini?), browser sends different User Agent strings for different request.
 24 | 
 25 | 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.
 26 | 
 27 | 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).
 28 | 
 29 | ## Firefox, Android
 30 | 
 31 | ### Problem: Cross-origin redirects for `<img />` tag cause Firefox to open Custom Tab browser
 32 | 
 33 | Bug Report: https://bugzilla.mozilla.org/show_bug.cgi?id=1515789
 34 | 
 35 | Status: Fix will be shipped in FF67
 36 | 
 37 | Cross-origin redirects for `<img />` tag cause Firefox to open Custom Tab browser, just like if Cross Origin navigation happen.
 38 | 
 39 | 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.
 40 | 
 41 | ## iOS Safari
 42 | 
 43 | Web App Manfest and ServiceWorker API are supported on iOS since 11.3.  
 44 | Reference: https://twitter.com/rmondello/status/956256845311590400
 45 | 
 46 | ### Problem: in iOS 12 cache in Cache Storage magically disappears
 47 | 
 48 | WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=190269
 49 | 
 50 | **Solution:**
 51 | 
 52 | This bug makes Cache Storage persist only until user closes Safari (or it's unloaded from memory).
 53 | Basically, the cache is some temporary place and is erased when Safari is closed.
 54 | There is really no workaround around this. It causes this situation.
 55 | 
 56 | - User visits a website
 57 | - ServiceWorker caches everything
 58 | - User closes Safari
 59 | - User visits a website again while offline
 60 | - Nothing loads
 61 | 
 62 | It also affects websites in standalone mode.
 63 | **This bug also prevents Safari from sharing the cache between standalone mode and normal Safari mode.**
 64 | 
 65 | 
 66 | ### Problem: Cookie/Login isn't shared between Safari and standalone mode
 67 | 
 68 | Problem is in all iOS version.
 69 | 
 70 | **Solution:**
 71 | 
 72 | At the time of writing (iOS 12.0.1), there is only couple version of Safari where the workaround works.
 73 | 
 74 | The workaround is to transfer a session through Cache Storage API, which has shared cache in some Safari versions.  
 75 | Approximately how the workaround works:
 76 | 
 77 | - User visits a website
 78 | - User opens the Share Popup to add website to the homescreen
 79 | - When popup opens, Safari sends `destination='manifeset'` request to the server
 80 | - ServiceWorker intercepts the requests and send another to the server to generate temporary token
 81 | - ServiceWorker stores the token in special cache in Cache Storage API
 82 | - User taps "Add to Homescreen"
 83 | - User opens website from the homescreen
 84 | - ServiceWorker intercepts the opening and send another request to the server with the saved token
 85 | - Server checks the token and authorizes the user
 86 | - ServiceWorker allows navigation to finish
 87 | - User is automatically authorized in standalone mode
 88 | 
 89 | Now gotchas.
 90 | 
 91 | 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.
 92 | WebKit Bug for iOS 12: https://bugs.webkit.org/show_bug.cgi?id=190269
 93 | 
 94 | Even though ServiceWorker was introduces in iOS 11.3, it's unknown if anything prior 11.4.1 can support this.
 95 | 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).
 96 | 
 97 | Tested on real devices with these versions: 
 98 | - 11.4.1 -- works
 99 | - 12.0.0 -- doesn't work
100 | - 12.0.1 -- doesn't work
101 | 
102 | ### Problem: Cross domain authorization in standalone mode doesn't work
103 | 
104 | This issue happens since 11.3 when Web App Manifest is used.  
105 | iOS requires `scope` property 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.
106 | 
107 | **Solution:**
108 | 
109 | Use the iframe. 
110 | 
111 | Let's suppose there is a foo.com website and its login is on login.foo.com  
112 | Here is approximately how this can be solved:
113 | 
114 | - Authorization request is sent to `foo.com`
115 | - ServiceWorker intercepts this request and cloned request to the server, with `redirect: 'manual'`
116 | - ServiceWorker tells the page to create `<iframe>` and request a fake url
117 | - ServiceWorker responds to the `<iframe>` fake url request with the response from syntetic request from the step 2
118 | - `<iframe>` handles the response. The response must have a redirect 
119 | - ServiceWorker intercepts the redirect from `<iframe>` and send another cloned request with `redirect: 'manual'`
120 | - If type of the response is `basic`, the send the response to original authorization from the step 1
121 | - If type of the response is `opaqueredirect`, repeat the steps from step 3
122 | 
123 | ### Problem: Sometimes PWA is added in normal mode and not standalone mode
124 | _(like there is no manifest at all)_
125 | 
126 | Reference: https://twitter.com/nekrtemplar/status/1040282198044291072
127 | 
128 | Safari fetches the manifest only when user is about to add the website to homescreen.
129 | To be preceice, manifest is fetched exactly when Share Popup is opened.
130 | 
131 | 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;
132 | Then in some cases the manifest might be fetched yet, so website will be added like there is no manifest.
133 | 
134 | **Solution:**
135 | 
136 | Thankfully, when Safari fetches the manifest,
137 | that request goes to the ServiceWorker with `request.destination` being `manifest`, as per spec.
138 | This means that it's possible to intercept such request and return manifest contents from the cache.
139 | So the solution would be to precache the manifest on ServiceWorker `install` and serve it to the browser from the cache.
140 | 
141 | 
142 | ### Problem: PWA is added without a splashscreen
143 | 
144 | Even if all correct splashscreen elements are added to the page, after adding the website to the home screen,
145 | it may not have the splashscreen. 
146 | 
147 | **Solution:**
148 | 
149 | When website is added only with Web App Manifest, Safari doesn't take splashscreen elements into the account. The solution would be adding `<meta name="apple-mobile-web-app-capable" content="yes">` element to the page alongside with the manifest.
150 | 
151 | _**Note:** It might be better adding `apple-mobile-web-app-capable` dynamically and only when in browser mode.
152 | When in standalone mode, it may affects URLs behavior since Web App Manifest installed PWA and `apple-mobile-web-app-capable`
153 | installed PWA have different URL behavior on iOS._
154 | 
155 | ### Problem: Navigation to a website has infinite loading
156 | 
157 | If update of a ServiceWorker happens when there is a page navigation in-flight and ServiceWorker `install` event resolves
158 | 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.
159 | 
160 | **Solution:**
161 | 
162 | Check for navigation requests when `install` event 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).
163 | 
164 | ### Problem: Push Notifications are not supported
165 | 
166 | 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.
167 | 
168 | **Solution:**
169 | 
170 | 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:
171 | - For Safari on Mac you can set up Push notifications using a proprietary implementation: https://developer.apple.com/notifications/safari-push-notifications/
172 | - The working (but cumbersome) solution is to wrap your PWA app into a native iOS one using, for example, Cordova.
173 | - 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.
174 | 
175 | ## Android
176 | 
177 | ### Problem: No migration on new Android phone
178 | 
179 | 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. 
180 | 


--------------------------------------------------------------------------------