When will IndexedDb be available as persistent storage?

[pshustad]

Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb as
the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota Management
API.

https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".

Does anyone know when this is planned to be implemented?

Regards,
Per

[David Grogan]

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb as
the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota Management
API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?

AFAIK this is not planned for the near future.

Have you looked into using a chrome app that requests unlimited storage in
the manifest? It might be a sufficient work around.

Regards,

Post by pshustad
Per
--
You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

[pshustad]

Yes, I have looked into the chrome app solution and see this as a possible
workaround. However, it requires more sophisticated users, as described here<http://support.google.com/chrome_webstore/bin/answer.py?hl=en&answer=2664769&p=crx_warning>
.
Anyway, thank you very much for your swift reply.

Post by David Grogan

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb
as the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota Management
API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?

AFAIK this is not planned for the near future.
Have you looked into using a chrome app that requests unlimited storage in
the manifest? It might be a sufficient work around.
Regards,

Post by pshustad
Per
--
You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

[Shachar Zohar]

Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb as
the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota Management
API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

[Joshua Bell]

There is now. :)

http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb
as the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota Management
API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

[subhranshu.das via Chromium HTML5]

Hi All,

Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?

Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb
as the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

[PhistucK]

I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.

☆*PhistucK*


On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using IndexedDb
as the Browser database. Currently, we are storing over 3 GB of data in
different object stores (~ 1 GB in each store) . We do not really want to
regard those data as temporary since our customers might be offline for a
long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

['Subhranshu Das' via Chromium HTML5]

Thanks for the reply.

Kust to clarify my understanding, so in a hypothetical scenario where the
disk space is nearly huge...as long as the USER doesn't explicitly wipe off
data from the browser the data in indexedDB is going to live ? even in the
3 scenarios i mentioned -

1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?

And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)

Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states that "The
plan is to put all HTML5 offline storage APIs—including IndexedDB,
Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/a/
chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/
chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/a/
chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout
.

[PhistucK]

I only know about Chrome, but it makes sense to me that all of the browsers
behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)

☆*PhistucK*


On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where the
disk space is nearly huge...as long as the USER doesn't explicitly wipe off
data from the browser the data in indexedDB is going to live ? even in the
3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states that
"The plan is to put all HTML5 offline storage APIs—including
IndexedDB, Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

[Joshua Bell]

There are some complications.

- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content settings

Cookies) that allow sites to be marked "Clear on exit', in which case the

data for those sites* is* cleared when the browser is closed.

Most browsers have some sort of "private browsing" concept like Incognito,
and presumably behave similarly. I'm unsure if they have "clear on exit"
options.

Otherwise, just to be explicit about Chrome's behavior:

- By default, storage is "best effort"; a site's data is retained until
heuristics kick in. Currently in Chrome, the heuristics are to use at most
a certain amount across all sites, and to retain a small amount of disk
space free. When those "storage pressure" conditions kick in, site data is
evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the site is
immune to storage pressure-based. In Chrome, the permission is granted
based on heuristics around site engagement, rather than explicitly
prompting the user.

Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.

Only Firefox also implements the persistent permission so far. All browsers
have different heuristics about retention and eviction, but as PhistucK
describes they have broadly similar behavior about retaining data across
sessions by default.

I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where the
disk space is nearly huge...as long as the USER doesn't explicitly wipe off
data from the browser the data in indexedDB is going to live ? even in the
3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states
that "The plan is to put all HTML5 offline storage APIs—including
IndexedDB, Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[PhistucK]

Does the "persistent" permission apply to IndexedDB? I seem to recall it
did not apply to it (I might be confusing storage mechanisms here).
What does it apply to?

☆*PhistucK*

Post by Joshua Bell
There are some complications.
- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content
settings > Cookies) that allow sites to be marked "Clear on exit', in which
case the data for those sites* is* cleared when the browser is closed.
Most browsers have some sort of "private browsing" concept like Incognito,
and presumably behave similarly. I'm unsure if they have "clear on exit"
options.
- By default, storage is "best effort"; a site's data is retained
until heuristics kick in. Currently in Chrome, the heuristics are to use at
most a certain amount across all sites, and to retain a small amount of
disk space free. When those "storage pressure" conditions kick in, site
data is evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the site
is immune to storage pressure-based. In Chrome, the permission is granted
based on heuristics around site engagement, rather than explicitly
prompting the user.
Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.
Only Firefox also implements the persistent permission so far. All
browsers have different heuristics about retention and eviction, but as
PhistucK describes they have broadly similar behavior about retaining data
across sessions by default.

Post by PhistucK
I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where
the disk space is nearly huge...as long as the USER doesn't explicitly wipe
off data from the browser the data in indexedDB is going to live ? even in
the 3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states
that "The plan is to put all HTML5 offline storage APIs—including
IndexedDB, Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google Groups
"Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout
.

[Joshua Bell]

Naming is unfortunately messy here.

Circa 2010 or so there was an earlier proposal for each origin to have two
storage namespaces, "PERSISTENT" and "TEMPORARY". The only APIs that
exposed this split were the Chrome-only webkitRequestFileSystem API
and webkitStorageInfo/navigator.webkitXXXStorage APIs. Other APIs (WebSQL,
Indexed DB, Cache API, ...) implicitly use the "TEMPORARY" namespace.

That was abandoned, and apart from those legacy, Chrome-only API surfaces
and plumbing in the code, what was called "TEMPORARY" is now just referred
to as the origin's default storage bucket in spec language, and behaves as
I described earlier in the thread. By default the persistence is "best
effort" but a permission can be granted elevating it to "persistent".

It's best to ignore the legacy "PERSISTENT" if you can, otherwise think of
it as some strange parallel universe of storage.

Post by PhistucK
Does the "persistent" permission apply to IndexedDB? I seem to recall it
did not apply to it (I might be confusing storage mechanisms here).
What does it apply to?
☆*PhistucK*

Post by Joshua Bell
There are some complications.
- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content
settings > Cookies) that allow sites to be marked "Clear on exit', in which
case the data for those sites* is* cleared when the browser is closed.
Most browsers have some sort of "private browsing" concept like
Incognito, and presumably behave similarly. I'm unsure if they have "clear
on exit" options.
- By default, storage is "best effort"; a site's data is retained
until heuristics kick in. Currently in Chrome, the heuristics are to use at
most a certain amount across all sites, and to retain a small amount of
disk space free. When those "storage pressure" conditions kick in, site
data is evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the site
is immune to storage pressure-based. In Chrome, the permission is granted
based on heuristics around site engagement, rather than explicitly
prompting the user.
Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.
Only Firefox also implements the persistent permission so far. All
browsers have different heuristics about retention and eviction, but as
PhistucK describes they have broadly similar behavior about retaining data
across sessions by default.

Post by PhistucK
I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where
the disk space is nearly huge...as long as the USER doesn't explicitly wipe
off data from the browser the data in indexedDB is going to live ? even in
the 3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states
that "The plan is to put all HTML5 offline storage APIs—including
IndexedDB, Application Cache, Files System, and other APIs that might be
specified—under the Quota Management API. You will be able to manage all
storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

[PhistucK]

Does that mean that the "persistent" permission applies to all of the
storage mechanisms in a permitted origin (WebSQL, Indexed DB, Cache API,
local storage, cookies... Am I missing more mechanisms?) except the file
system API?

☆*PhistucK*

Post by Joshua Bell
Naming is unfortunately messy here.
Circa 2010 or so there was an earlier proposal for each origin to have two
storage namespaces, "PERSISTENT" and "TEMPORARY". The only APIs that
exposed this split were the Chrome-only webkitRequestFileSystem API
and webkitStorageInfo/navigator.webkitXXXStorage APIs. Other APIs (WebSQL,
Indexed DB, Cache API, ...) implicitly use the "TEMPORARY" namespace.
That was abandoned, and apart from those legacy, Chrome-only API surfaces
and plumbing in the code, what was called "TEMPORARY" is now just referred
to as the origin's default storage bucket in spec language, and behaves as
I described earlier in the thread. By default the persistence is "best
effort" but a permission can be granted elevating it to "persistent".
It's best to ignore the legacy "PERSISTENT" if you can, otherwise think of
it as some strange parallel universe of storage.

Post by PhistucK
Does the "persistent" permission apply to IndexedDB? I seem to recall it
did not apply to it (I might be confusing storage mechanisms here).
What does it apply to?
☆*PhistucK*

Post by Joshua Bell
There are some complications.
- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content
settings > Cookies) that allow sites to be marked "Clear on exit', in which
case the data for those sites* is* cleared when the browser is closed.
Most browsers have some sort of "private browsing" concept like
Incognito, and presumably behave similarly. I'm unsure if they have "clear
on exit" options.
- By default, storage is "best effort"; a site's data is retained
until heuristics kick in. Currently in Chrome, the heuristics are to use at
most a certain amount across all sites, and to retain a small amount of
disk space free. When those "storage pressure" conditions kick in, site
data is evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the
site is immune to storage pressure-based. In Chrome, the permission is
granted based on heuristics around site engagement, rather than explicitly
prompting the user.
Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.
Only Firefox also implements the persistent permission so far. All
browsers have different heuristics about retention and eviction, but as
PhistucK describes they have broadly similar behavior about retaining data
across sessions by default.

Post by PhistucK
I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where
the disk space is nearly huge...as long as the USER doesn't explicitly wipe
off data from the browser the data in indexedDB is going to live ? even in
the 3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states
that "The plan is to put all HTML5 offline storage
APIs—including IndexedDB, Application Cache, Files System, and other APIs
that might be specified—under the Quota Management API. You will be able to
manage all storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

[Joshua Bell]

The "persistent" permission applies to all of those *and* the file system
API's "TEMPORARY" namespace too.

A quick attempt at a diagram here:

https://docs.google.com/drawings/d/1K1fn6FawDITsiChAZ7pcVolee9EMNHo5xYV3prt4pmY/edit?usp=sharing

Re: more mechanisms: Service Worker storage (registrations, script cache,
etc) is a storage API. Background Fetch storage is being treated this way
too for the purposes of quota. Local Storage is handled differently for the
purposes of quota, but has the same persistence guarantees as the other
types.

Post by PhistucK
Does that mean that the "persistent" permission applies to all of the
storage mechanisms in a permitted origin (WebSQL, Indexed DB, Cache API,
local storage, cookies... Am I missing more mechanisms?) except the file
system API?
☆*PhistucK*

Post by Joshua Bell
Naming is unfortunately messy here.
Circa 2010 or so there was an earlier proposal for each origin to have
two storage namespaces, "PERSISTENT" and "TEMPORARY". The only APIs that
exposed this split were the Chrome-only webkitRequestFileSystem API
and webkitStorageInfo/navigator.webkitXXXStorage APIs. Other APIs (WebSQL,
Indexed DB, Cache API, ...) implicitly use the "TEMPORARY" namespace.
That was abandoned, and apart from those legacy, Chrome-only API surfaces
and plumbing in the code, what was called "TEMPORARY" is now just referred
to as the origin's default storage bucket in spec language, and behaves as
I described earlier in the thread. By default the persistence is "best
effort" but a permission can be granted elevating it to "persistent".
It's best to ignore the legacy "PERSISTENT" if you can, otherwise think
of it as some strange parallel universe of storage.

Post by PhistucK
Does the "persistent" permission apply to IndexedDB? I seem to recall it
did not apply to it (I might be confusing storage mechanisms here).
What does it apply to?
☆*PhistucK*

Post by Joshua Bell
There are some complications.
- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content
settings > Cookies) that allow sites to be marked "Clear on exit', in which
case the data for those sites* is* cleared when the browser is closed.
Most browsers have some sort of "private browsing" concept like
Incognito, and presumably behave similarly. I'm unsure if they have "clear
on exit" options.
- By default, storage is "best effort"; a site's data is retained
until heuristics kick in. Currently in Chrome, the heuristics are to use at
most a certain amount across all sites, and to retain a small amount of
disk space free. When those "storage pressure" conditions kick in, site
data is evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the
site is immune to storage pressure-based. In Chrome, the permission is
granted based on heuristics around site engagement, rather than explicitly
prompting the user.
Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.
Only Firefox also implements the persistent permission so far. All
browsers have different heuristics about retention and eviction, but as
PhistucK describes they have broadly similar behavior about retaining data
across sessions by default.

Post by PhistucK
I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down. The
whole point of having a storage mechanism is that it will persist (at least
a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario where
the disk space is nearly huge...as long as the USER doesn't explicitly wipe
off data from the browser the data in indexedDB is going to live ? even in
the 3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage states
that "The plan is to put all HTML5 offline storage
APIs—including IndexedDB, Application Cache, Files System, and other APIs
that might be specified—under the Quota Management API. You will be able to
manage all storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the
Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

[PhistucK]

Thank you fro the clarification!

☆*PhistucK*

Post by Joshua Bell
The "persistent" permission applies to all of those *and* the file system
API's "TEMPORARY" namespace too.
https://docs.google.com/drawings/d/1K1fn6FawDITsiChAZ7pcVolee9EMNHo5xYV3prt4pmY/edit?usp=sharing
Re: more mechanisms: Service Worker storage (registrations, script cache,
etc) is a storage API. Background Fetch storage is being treated this way
too for the purposes of quota. Local Storage is handled differently for the
purposes of quota, but has the same persistence guarantees as the other
types.

Post by PhistucK
Does that mean that the "persistent" permission applies to all of the
storage mechanisms in a permitted origin (WebSQL, Indexed DB, Cache API,
local storage, cookies... Am I missing more mechanisms?) except the file
system API?
☆*PhistucK*

Post by Joshua Bell
Naming is unfortunately messy here.
Circa 2010 or so there was an earlier proposal for each origin to have
two storage namespaces, "PERSISTENT" and "TEMPORARY". The only APIs that
exposed this split were the Chrome-only webkitRequestFileSystem API
and webkitStorageInfo/navigator.webkitXXXStorage APIs. Other APIs (WebSQL,
Indexed DB, Cache API, ...) implicitly use the "TEMPORARY" namespace.
That was abandoned, and apart from those legacy, Chrome-only API
surfaces and plumbing in the code, what was called "TEMPORARY" is now just
referred to as the origin's default storage bucket in spec language, and
behaves as I described earlier in the thread. By default the persistence is
"best effort" but a permission can be granted elevating it to "persistent".
It's best to ignore the legacy "PERSISTENT" if you can, otherwise think
of it as some strange parallel universe of storage.

Post by PhistucK
Does the "persistent" permission apply to IndexedDB? I seem to recall
it did not apply to it (I might be confusing storage mechanisms here).
What does it apply to?
☆*PhistucK*

Post by Joshua Bell
There are some complications.
- In Incognito mode the data is only retained until the end of the
session (e.g. incognito window is closed)
- There are options in settings (Privacy and security > Content
settings > Cookies) that allow sites to be marked "Clear on exit', in which
case the data for those sites* is* cleared when the browser is closed.
Most browsers have some sort of "private browsing" concept like
Incognito, and presumably behave similarly. I'm unsure if they have "clear
on exit" options.
- By default, storage is "best effort"; a site's data is retained
until heuristics kick in. Currently in Chrome, the heuristics are to use at
most a certain amount across all sites, and to retain a small amount of
disk space free. When those "storage pressure" conditions kick in, site
data is evicted on an LRU basis.
- Sites can request the "persistent" permission. If granted, the
site is immune to storage pressure-based. In Chrome, the permission is
granted based on heuristics around site engagement, rather than explicitly
prompting the user.
Additionally, regardless of permissions, if the user manually clears
browsing data then the data is wiped.
Only Firefox also implements the persistent permission so far. All
browsers have different heuristics about retention and eviction, but as
PhistucK describes they have broadly similar behavior about retaining data
across sessions by default.

Post by PhistucK
I only know about Chrome, but it makes sense to me that all of the
browsers behave more or less the same.
Nothing is evacuated when the tab, browser or system is shut down.
The whole point of having a storage mechanism is that it will persist (at
least a bit).
(Even those old cookies can persist system shutdowns)
☆*PhistucK*
On Sat, May 26, 2018 at 6:21 AM Subhranshu Das <

Post by 'Subhranshu Das' via Chromium HTML5
Thanks for the reply.
Kust to clarify my understanding, so in a hypothetical scenario
where the disk space is nearly huge...as long as the USER doesn't
explicitly wipe off data from the browser the data in indexedDB is going to
live ? even in the 3 scenarios i mentioned -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile
browsers as well)
Regards,
Subhranshu

Post by PhistucK
I think it is wiped out when the disk space is relatively low.
I believe a persistent storage will never be wiped out.
☆*PhistucK*
On Sat, May 26, 2018 at 1:19 AM subhranshu.das via Chromium HTML5 <

Post by subhranshu.das via Chromium HTML5
Hi All,
Storage Newbie here... Does the data in indexedDB gets wiped out
when user -
1. closes the browser tab. ?
2. closes the browser ?
3. shuts down the PC ?
Regards,
Subhranshu Das

Post by Joshua Bell
There is now. :)
http://crbug.com/340350

Post by Shachar Zohar
Is there an issue for this?

Post by pshustad
Hi.
We are implementing an HTML5 offine-enabled application using
IndexedDb as the Browser database. Currently, we are storing over 3 GB of
data in different object stores (~ 1 GB in each store) . We do not really
want to regard those data as temporary since our customers might be offline
for a long time and need access to the system at all times. We have started
getting problems with the temporary storage space getting exhausted and
look forward to switch to persistent storage, using the Quota
Management API.
https://developers.google.com/chrome/whitepapers/storage
states that "The plan is to put all HTML5 offline storage
APIs—including IndexedDB, Application Cache, Files System, and other APIs
that might be specified—under the Quota Management API. You will be able to
manage all storage allocation with it".
Does anyone know when this is planned to be implemented?
Regards,
Per

--
You received this message because you are subscribed to the
Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from
Visit this group at
http://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/groups/opt_out.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.

--

You received this message because you are subscribed to the Google
Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at
https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit
https://groups.google.com/a/chromium.org/d/optout.