Status: Unconfirmed
Owner: ----
Labels: Cr-Enterprise Pri-2 Via-Wizard Type-Bug OS-Chrome
New issue 406437 by
tren...@fallsoftware.com: Clearing webview cache, or an
effective workaround for kiosk mode apps.
https://code.google.com/p/chromium/issues/detail?id=406437
UserAgent: Mozilla/5.0 (X11; CrOS x86_64 5841.98.0) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Platform: 5841.98.0 (Official Build) stable-channel lumpy
Steps to reproduce the problem:
1. use a webview to serve content from within an application
2. deploy an update to that content
3. Observe there is no way to fully update the content of the application
before the cache-control indicates that the content has gone stale and the
webview fetches the update automatically on the next request.
What is the expected behavior?
There should be either a manifest setting that allows programmatic
access/setting of the webview cache, or an extension of the
<webview>.clearData api to include cache clearing.
What went wrong?
This application is deployed across Android, iOS, OSX, Linux and Windows,
and Cros, and this is a real sticking point for testing our deployments
chrome app deployments effectively. The most critical case would be a
Chromebook that is using the chrome app in kiosk mode.
The only options we have (that I can think of), other than this kind of
change, would be to hard refresh from within the weview, then ask the user
to restart the application, which is a bad UX and does not provide refresh
guarantees for asynchronously acquired resources, or for us to maintain
different server configurations for testing (no-cache) and prod (stale
after X hours), which is really undesirable.
Did this work before? No
Chrome version: 36.0.1985.143 Channel: stable
OS Version: 5841.98.0
Flash Version: Shockwave Flash 14.0 r0
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings