Solved. The problem with the footer becoming un-anchored was apparently caused by our partner’s website, which was set to rotate to landscape mode. When they changed their setting, the problem disappeared.

We created an absolutely positioned div “off screen” anchored to the top of the viewport, that would provide a black background under the status bar area of X-series iPhones (for other reasons we had to make the status bar transparent). The redirect was un-anchoring that div. The solution was to move the anchor point so at least part of the div was on-screen (I used 100vh - 10px, anchored to the bottom of the screen. The div had a fixed height that extended above the top of the screen). Including here for reference in case anyone else has a similar issue.

I’ll add my observations, because I think this will be a recurring issue for lots of people.

From what I’ve seen, Quasar will automatically check for the existence of a new service worker when it loads. However by default, a PWA won’t start using the new service worker until it is completely shut down and restarted. Simply reloading, or even hard-refreshing the page won’t work (and PWAs in standalone mode don’t always have a refresh button available). This is particularly problematic on iOS at the moment - when you close a PWA, iOS “freezes” the state of the app rather than shutting it down. And there’s no way to easily shut down the app. I’ve found going into the settings for Safari and doing a full cache clear will let a new service worker take over the PWA, and the updated version will appear.

Enabling the skipWaiting() setting (which can be done in the quasar.conf.js file) will the PWA to start using the new service worker as soon as possible. The observed behaviour flow: app loads up, PWA checks for new service worker, identifies a new one is available and installs it. If the page is reloaded or revisited, the new service worker will take over and the updated version will display. The updated version isn’t shown absolutely immediately, but it is shown pretty fast.

One potential issue I’ve seen (not 100% confirmed). Using skipWaiting() in conjunction with lazy loading is a known potential risk: a new service worker might try to load content that is in control of the older service worker. We’ve seen new content load up, navigate to a different page, navigate back and the old version is displaying.

Edit: iOS 13 (coming out in a couple of weeks) brings back the ability to force quit a PWA. That might also influence the decision of whether to use skipWaiting().

Further update now that that iOS 13 has been released.

I removed skipWaiting() and clientClaim() from our configuration settings. I can open our PWA and it will show the old version. After closing the app via the app switcher, when the app restarts, it has updated to the new version. iOS might close a suspended PWA after a certain amount of time has passed without any user action, although as with most things PWA related on iOS, information from Apple is scarce.

Rejoining this thread, because I’ve figured out a complete solution for a user controlled app refresh (similar to the pop-up in the Quasar documentation) that might be useful for others who have the same issue. It’s a combination of ideas taken from the Workbox Advanced Recipes (https://developers.google.com/web/tools/workbox/guides/advanced-recipes#offer_a_page_reload_for_users) and an article by Doug Allrich. It uses the Workbox-Window plug-in from Google.

<template>
  <q-dialog v-model="displayUpdatePrompt">
    <q-banner>
      A new version is available.
     <template v-slot:action>
       <q-btn label="Update" @click="refreshApp" />
     </template>
   </q-banner>
  <q-dialog>
</template>

<script>
import { Wokbox } from 'workbox-window'

export default {
data() {
  return {
  displayUpdatePrompt: false,
  workbox: null,
  }
},
methods: {
  refreshApp() {
    this.workbox.addEventListener('controlling', () => {
      window.location.reload()
    })
   this.workbox.messageSkipWaiting()
  }
},
created() {
  if ('service-worker' in navigator) {
    this.workbox = new Workbox('/service-worker.js')

   this.workbox.addEventListener('waiting', (event) => {
    this.displayUpdatePrompt = true
    })
    this.workbox.register()
  }
}
}
</script>

Rejoining this thread, because I’ve figured out a complete solution for a user controlled app refresh (similar to the pop-up in the Quasar documentation) that might be useful for others who have the same issue. It’s a combination of ideas taken from the Workbox Advanced Recipes (https://developers.google.com/web/tools/workbox/guides/advanced-recipes#offer_a_page_reload_for_users) and an article by Doug Allrich. It uses the Workbox-Window plug-in from Google.

<template>
  <q-dialog v-model="displayUpdatePrompt">
    <q-banner>
      A new version is available.
     <template v-slot:action>
       <q-btn label="Update" @click="refreshApp" />
     </template>
   </q-banner>
  <q-dialog>
</template>

<script>
import { Wokbox } from 'workbox-window'

export default {
data() {
  return {
  displayUpdatePrompt: false,
  workbox: null,
  }
},
methods: {
  refreshApp() {
    this.workbox.addEventListener('controlling', () => {
      window.location.reload()
    })
   this.workbox.messageSkipWaiting()
  }
},
created() {
  if ('service-worker' in navigator) {
    this.workbox = new Workbox('/service-worker.js')

   this.workbox.addEventListener('waiting', (event) => {
    this.displayUpdatePrompt = true
    })
    this.workbox.register()
  }
}
}
</script>

Posting a solution for this issue in case anyone ran into it like I did, and stumbled on this post. In my case the problem was created by declaring the model field as an empty string. Declaring it as either “null” (as per the Quasar documentation) or an empty array fixes the issue.

I did an update on my Node packages, and now my project is breaking during compile. I get messages that specific modules or dependencies can’t be found. My project has a mix of javascript and Typescript files, and all of the files that can’t be found are Typescript files. I have deleted node_modules, package-lock.json and the .quasar folder and re-run npm install many times. I’ve encountered the same issues when updating other projects and was able to get past the blockages eventually, but I can’t remember which particular change might have fixed the problem on the other projects. Another project has the exact same dependencies in the package-json and runs fine.

The packages I’m using are below:

“dependencies”: {
“@bugsnag/js”: “^6.5.2”,
“@quasar/extras”: “^1.7.0”,
“@types/jquery”: “^3.3.32”,
“axios”: “^0.19.2”,
“core-js”: “^2.6.9”,
“jquery”: “^3.4.1”,
“quasar”: “1.5.8”,
“socket.io-client”: “^2.3.0”,
“vue-slick-carousel”: “^1.0.2”,
“vue-touch-keyboard”: “^0.3.2”
},
“devDependencies”: {
“@quasar/app”: “1.8.5”,
“@quasar/quasar-app-extension-testing”: “^1.0.0”,
“@quasar/quasar-app-extension-testing-unit-jest”: “^1.0.0”,
“@quasar/quasar-app-extension-typescript”: “^1.0.0-beta.2”,
“@types/node”: “11.9.5”,
“@typescript-eslint/eslint-plugin”: “^1.12.0”,
“@typescript-eslint/parser”: “^1.12.0”,
“devtron”: “^1.4.0”,
“electron”: “^7.1.12”,
“electron-debug”: “^3.0.1”,
“electron-devtools-installer”: “^2.2.4”,
“electron-packager”: “^14.2.1”,
“typescript”: “^3.8.3”
},

We’re experimenting with creating a Cordova-wrapped version of our PWA which is a Typescript project. After adding the Cordova mode, adding ios as a platform, then running the Quasar dev command, I get an error message that tsconfig.json can’t be found in the root directory. Manually copying tsconfig.json to /src-cordova fixes the issue.

Is this something that should potentially be handled automatically in “quasar mode cordova” or similar?

Further update now that that iOS 13 has been released.

I removed skipWaiting() and clientClaim() from our configuration settings. I can open our PWA and it will show the old version. After closing the app via the app switcher, when the app restarts, it has updated to the new version. iOS might close a suspended PWA after a certain amount of time has passed without any user action, although as with most things PWA related on iOS, information from Apple is scarce.

@motia I’m trying to use your package to integrate OneSignal with our app. I’ve got to the point where there are no visible errors (eg it’s getting the right API key and not complaining about the domain), but app.$oneSignal.setup(apiKey) doesn’t seem to actually be doing anything I can see.

I’m using OneSignal’s “Typical Site Setup” with a slide prompt. My expectation is that when the setup method is triggered from app.vue, the slide prompt will appear. Does your package require using OneSignal’s Custom Code setting with my own prompt?

I’ll add my observations, because I think this will be a recurring issue for lots of people.

From what I’ve seen, Quasar will automatically check for the existence of a new service worker when it loads. However by default, a PWA won’t start using the new service worker until it is completely shut down and restarted. Simply reloading, or even hard-refreshing the page won’t work (and PWAs in standalone mode don’t always have a refresh button available). This is particularly problematic on iOS at the moment - when you close a PWA, iOS “freezes” the state of the app rather than shutting it down. And there’s no way to easily shut down the app. I’ve found going into the settings for Safari and doing a full cache clear will let a new service worker take over the PWA, and the updated version will appear.

Enabling the skipWaiting() setting (which can be done in the quasar.conf.js file) will the PWA to start using the new service worker as soon as possible. The observed behaviour flow: app loads up, PWA checks for new service worker, identifies a new one is available and installs it. If the page is reloaded or revisited, the new service worker will take over and the updated version will display. The updated version isn’t shown absolutely immediately, but it is shown pretty fast.

One potential issue I’ve seen (not 100% confirmed). Using skipWaiting() in conjunction with lazy loading is a known potential risk: a new service worker might try to load content that is in control of the older service worker. We’ve seen new content load up, navigate to a different page, navigate back and the old version is displaying.

Edit: iOS 13 (coming out in a couple of weeks) brings back the ability to force quit a PWA. That might also influence the decision of whether to use skipWaiting().

Solved. The problem with the footer becoming un-anchored was apparently caused by our partner’s website, which was set to rotate to landscape mode. When they changed their setting, the problem disappeared.

We created an absolutely positioned div “off screen” anchored to the top of the viewport, that would provide a black background under the status bar area of X-series iPhones (for other reasons we had to make the status bar transparent). The redirect was un-anchoring that div. The solution was to move the anchor point so at least part of the div was on-screen (I used 100vh - 10px, anchored to the bottom of the screen. The div had a fixed height that extended above the top of the screen). Including here for reference in case anyone else has a similar issue.

Hoping someone else may have found a solution for this. I’m writing unit tests for our PWA at the moment. We have a number of functions that call openURL. I just want to create a mock for openURL to check that it has been called correctly. So far every solution I’ve tried has broken the unit test and generated a “TypeError: Cannot read property 'electron” of undefined" error.

I have an error that seems to only crop up in a very narrow set of circumstances. I have a PWA with a fixed header and footer. We link to a partner website to handle user log-in, after which they are redirected back to the PWA. Everything seems to work fine… except on the iPhone X. As the page is scrolled, the footer slides up to the middle of the page, and the header slides off it completely. The issue only occurs when the web app is installed as a PWA, not when visiting the web site through Safari. Research seems to show there is a history of “position: fixed” elements breaking on iOS, but I haven’t found any clear solutions. Anyone encountered something similar, or have any suggestions?