Reconsider profile downgrade behavior |
||||
Issue descriptionChrome does not support profile downgrades, i.e. switching from "beta" to "stable" channel with the same profile has undefined behavior. Recent bugs (issue 698214) highlight that this can also happen due to chromium development practices - e.g. a change could be rolled back within a channel, outside of a user's control. This particularly affects offline storage features (Indexed DB, Cache Storage, etc) which can suddenly be faced with data "from the future" that can't be interpreted by current code. Currently, storage features handle this independently. For example, Indexed DB records the current data version into the backing store and checks on open. When data "from the future" is seen it is treated as corruption and the backing store is wiped. There are a variety of factors to consider with impact on Chrome development and users. * Treating storage types separately vs. wiping all data for an origin. Some web applications will be confused if the data becomes inconsistent (e.g. "why do localstorage and IDB disagree?"); others want to use this as a signal (e.g. a sentinel in localstorage indicating there was data loss) * Avoiding data loss: A storage type could simply refuse to "open" in the face of version skew. This was initially rejected because it left the web application in an untenable state - the app can't recover, and the user is unlikely to know how to recover (delete data or upgrade browser). In the case of a reverted change, the data may never be recoverable. * Avoiding unexpected behavior: Some storage types could continue functioning, e.g. allowing the storage to "open" if the metadata is understandable, but then give dummy values like null or errors to script when unparsable records are encountered. This is generally rejected because it will violate specified behavior.
,
Apr 19 2017
See also issue 373987 - which would let you run channels side-by-side; this would address the biggest user-triggered source of version skew.
,
Apr 19 2017
,
Apr 27 2017
I think the proposal in #1 would have a significant negative impact on development speed. We'd effectively lose the benefits of the Dev channel because without a writer, the new reader code would never get used. Also, it's not quite a silver bullet, as users going Dev -> Stable (2 releases) would still be impacted. I do think that we should be resilient to disk corruption, in the sense that we should not crash, and we should not return incorrect data. Specifically, in the IndexedDB case, we currently return nulls when we fail to deserialize data, and that is unfortunate. We should throw exceptions or abort transactions. (IIRC, we're already tracking this issue) In return, Web apps should assume that IDB is a cache that can be wiped at any time, as we want to be able to do that in low space cases anyway. I think this is a DevRel issue, and AFAIK at least large apps are doing it right. I wonder if we can treat version skew exactly like header corruption, and delete the database.
,
Apr 27 2017
,
May 28 2017
Might we want to take a different stance in the case of durable storage? Eg. If the data is my 4 hours of offline email I wrote on a plane, I really don't want it treated as a cache (real scenario for me - extremely frustrating). In that case, throwing (or even crashing) where the only fix is to install the version of Chrome which understands the format is probably the best possible solution.
,
Jun 5 2017
,
Aug 9
Changing owners. Still unlikely to be something we'll address any time soon. FWIW, I heard somewhere recently that Chrome now wipes profile on downgrade, but I may have misheard or be misremembering the exact semantics. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jsb...@chromium.org
, Apr 19 2017