There are a lot of quirks with Safari that are similar to the way IE6 eventually stopped following standards.
That fact that localstorage doesnt work in private mode is 1 example.
That fact that localstorage doesnt work in private mode is 1 example.
If your site relies on using localstorage during the lifecycle of an individual page, you can always replace it with an in-memory mock polyfill if you notice it's missing. There's probably an NPM package for that.
It's certainly not the approach everyone would be happy with, but it allows developers much more flexibility than the contrary case, where private browsing is a silent effect that might make apps do very stupid things (like, say, downloading the same huge asset bundle into localStorage over and over.)
This would happen anyway no matter what storage or cache is used since all data is cleared after private browsing session is over.
Breaking localstorage (with an over-quota error) is not the way to deal with this. Polyfills are just more crap in complexity and downloaded bytes to compensate for a browser's issues.
It would be much better to have a navigator.isPrivate flag enabled so apps can check the environment accurately, not guess based on whether certain APIs work or not. It's not about SLAs but supporting standards. Deleting client-side data is all that private browsing needs to do.
Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.
From the Web Storage spec: "[localStorage] is designed for storage that spans multiple windows, and lasts beyond the current session."[1] Thus if a browser is discarding localStorage prior to the end of the current session, it's explicitly against the spec.
This is more than academic. If apps aren't written to explicitly use ephemeral storage then they may not function as expected in private mode, like, say, unexpectedly causing data loss.