But what do end users or developers expect in terms of browser behavior in
this situation?

The history api (or saving state to indexedDB) aren't going to solve the
problem of reinitialization everytime the user switches back to a web app.
Users expect them to behave like a native app.

The early iPads were low powered devices and many app developers used to
ship content as  images because they couldn't render complex layouts
quickly, but newer tablets are far more powerful and can handle this.

Chrome handles this as users and developers expect, web apps get paged out
and require a reload depending on memory etc. Safari does it every single

This is a massive barrier against web apps competing against native apps.
On 10 Jun 2015 6:21 am, "Domenic Denicola" <d...@domenic.me> wrote:

> I'm pretty sure it's out of scope. That's really asking to specify how
> OS-level task switching works. I imagine that Safari-wrapper or whatever
> has decided that when the OS switches back to it it will do a reload, just
> like when I switch back to my mail app it does a sync, and other stuff like
> that.
> > -----Original Message-----
> > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac
> > Spitzer
> > Sent: Monday, June 8, 2015 21:10
> > To: wha...@whatwg.org
> > Subject: [whatwg] Persistent state for homescreen web apps (without
> > reloading each time)
> >
> > Is it within the scope of the spec to specify whether home screen web
> apps
> > should retain their loaded state when switching from foreground to
> > background and back to foreground again?
> >
> > Chrome behaves exactly as expected, however, iOS reloads the web app
> > each time
> >
> > http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-
> > ios-home.html
> >
> > --
> > Zac Spitzer
> > +61 405 847 168

Reply via email to