Closed GoogleCodeExporter closed 9 years ago
Updated to Chromium revision 138235 in CEF revision 644.
Original comment by magreenb...@gmail.com
on 23 May 2012 at 7:02
With this new version of CEF, if I understand well, there is no way to get
persistent storage as of now. Is this right? If so I'm stuck with an older
version of libcef for now...
Original comment by raynaudq...@gmail.com
on 12 Jun 2012 at 1:00
If no one else is working on this... Are there any suggestions/pointers on
where to start working on a patch to support persistence?
Original comment by gusver...@gmail.com
on 21 Jun 2012 at 5:31
The new storage class in CEF is BrowserDomStorageSystem from
libcef/browser_dom_storage_system.[cc|h]. The equivalent implementation for
Chromium lives in /content/renderer/dom_storage and
/content/browser/dom_storage. These classes are lightweight wrappers around the
DOM storage implementation in /webkit/dom_storage. Achieving persistent storage
may only require the passage of valid file paths (based on
CefSettings.cache_path) to the DomStorageContext object created in the
BrowserDomStorageSystem constructor, but I haven't tested this theory.
Additional work would then be required to programmatically retrieve the storage
information, allow modification of the storage path, etc.
Original comment by magreenb...@gmail.com
on 21 Jun 2012 at 5:45
Thanks for the pointers!
Attached is a quick-n-dirty solution to support persistent local storage.
Original comment by gusver...@gmail.com
on 21 Jun 2012 at 9:55
Attachments:
Thanks, committed as revision 704 with the following change: moved blocking
pool creation to the UI thread so that it works with multi-threaded message
loop mode as well.
Implementation of cef_storage.h using the new API is now issue #658.
Original comment by magreenb...@gmail.com
on 22 Jun 2012 at 3:11
Original issue reported on code.google.com by
magreenb...@gmail.com
on 23 May 2012 at 6:43