Can reproduce segfault on all platforms in Chrome 51 with:



const webview = document.createElement('webview');
webview.setAttribute('id', 'player');
webview.setAttribute('partition', 'persist:player');
webview.setAttribute('src', 'http://example.com'); 
webview.addEventListener('contentload', () => {
  webview.clearData({}, { cache: true });
  webview.clearData({}, { cache: true });
});
document.body.appendChild(webview);



Seeing the segfault in other, harder to isolate situations, e.g. when clearData is called after page in webview writes to local storage and reloads.

Thanks folks for the report!
Seems like there are multiple issues here.

1) From original post:
Q: The code in our packaged app calls the clearData method on our webview and then sets the src attribute of the webview to the URL we want to load.

A: Generally if the <webview> hasn't loaded anything, clearData() call will return false and do nothing, because the <webview> isn't associated with any site yet.
Think this method as to clear an existing <webview>'s data. i.e. <webview> loads example.com then you call clearData, once the callback of clearData is called, you can expect the data to be cleared. So next time you load example.com (by setting src), it would start fresh.

Not entirely sure if that answers your concern, @jason.sobanski?


2) In cases where you don't see the callback getting called ever, can you check if webview.clearData() call is returning false? Same as #1 above, this would mean the webview hasn't loaded anything effective yet to clear.

3) From original post and comment #2, I can repro the segfault, I'll try to fix it ASAP.
This regressed due to r380598 (/cc leon.han just for FYI).
I'm not sure why I needed to call both:
a. WebCacheManager::ClearCacheForProcess(renderer_id) and
b. WebCacheManager::Remove(renderer_id)
The latter (b) seems redundant and is causing problems after r380598. I only vaguely remember that clearing http cache wasn't working without it before, but now as I check it, my local testing seems to succeed without calling b.
I'll be removing calling b.

Just responding to the questions asked of me.  

1 - I'd like to be able to clear the cache prior to loading the site if possible.  The webview cache does seem to persist even if the app (and webview) is restarted (I use a persistent storage partition for the webview, so that may play into that?), so we are looking to clear any cache that may be around from the previous run of the app.  I had thought clearData was working as I was expecting after support for the HTTP cache clearing was initially added, but I hadn't been watching it closely so I may have been mistaken.  I can likely work around this however as long as the segfault problem is fixed.

2 - In the cases where I'm not seeing the callback, I did verify that clearData was returning false.  When I called it again later once the page was loaded, it returned true.  

Thanks for the information about this API, I should be able to make it work how I need now. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d0dae71f785f35d100d1454e3a7331a896bdf2f2

commit d0dae71f785f35d100d1454e3a7331a896bdf2f2
Author: lazyboy <lazyboy@chromium.org>
Date: Fri Jun 03 21:20:05 2016

Don't call WebCacheManager::Remove(RPH_id) to clear webview's cache.

We already call WebCacheManager::ClearCacheForProcess(RPH_id), which
seems to be sufficient in my local testing.
I remember that clearing webview cache didn't seem to work without calling
WCM::Remove() when I implemented it.

After r380598, Calling WCM::Remove also deletes mojo service associated
with the RPH, so the next call to WCM::Remove with the same RPH will
result in a nullptr access.

BUG= 615429 
Test=Added a test, see  http://crbug.com/615429#c2  for repro.

Review-Url: https://codereview.chromium.org/2033993002
Cr-Commit-Position: refs/heads/master@{#397803}

[modify] https://crrev.com/d0dae71f785f35d100d1454e3a7331a896bdf2f2/chrome/browser/apps/guest_view/web_view_browsertest.cc
[add] https://crrev.com/d0dae71f785f35d100d1454e3a7331a896bdf2f2/chrome/test/data/extensions/platform_apps/web_view/common/cleardata_twice/bootstrap.js
[add] https://crrev.com/d0dae71f785f35d100d1454e3a7331a896bdf2f2/chrome/test/data/extensions/platform_apps/web_view/common/cleardata_twice/guest.html
[modify] https://crrev.com/d0dae71f785f35d100d1454e3a7331a896bdf2f2/extensions/browser/guest_view/web_view/web_view_guest.cc

Any updates on when this fix might get released?  I'm not able to work around this very well when I'm risking a crash from trying to clear the cache.  Our QC testers report that the cache appeared to be cleared in the past (as recently as February 2016) when clearData was called before the SRC attribute was set.  If this API never did (and won't in the future) work like this however, then I'll have to clear on loadstart once the crash risk goes away.

It may be worth clarifying how this API works in the documentation also.  There is nothing that specifies this has to be called after the webview has a SRC attribute set or that you are only clearing the cache for the currently loaded host.  In my situation, I am not really as concerned with clearing the cache of items cached during the current lifetime of the webview as I am in clearing items cached during a previous run of the app.  Again, not sure if the persistent storage partition is playing into that behavior.  

Users experienced this crash on the following builds:

Win Stable 51.0.2704.103 -  32.24 CPM, 9 reports, 1 clients (signature web_cache::WebCacheManager::ClearRendererCache)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

This is fixed in r397803, so it should be available in m53. The regression was at r380598, so this would still be broken in m52.

Note that this applies to all platforms.

re: comment #8 regarding documentation, I'll add a little bit of documentation to state the subtlety in clearData method, thanks for bringing this up!

krishnargv@ - can you help test this using 1 of the test kios apps? You'll need to call Webview clearData method. See comment 2 https://bugs.chromium.org/p/chromium/issues/detail?id=615429#c2


lazyboy@ - how can we verify whether webview cache is cleared or not?

@harpreet, I generally check from network tab of devtools, load a page with images, etc and see if webview.reload() loads most of the (cache-able) resources from cache.
A quick search shows that you can use this page to test whether the image in the page is loaded from cache or not: http://refreshyourcache.com/en/cache-test/, not sure how reliable that is though. But the general idea is to load webview pointing to the url, then call webview.reload() multiple times and verify that the image is being served from cache (i.e. the broken image will appear), then call clearData on the webview, then reload webview and you'll see that the image was served from the network.

I am working on verifying the fix. Will update the bug once i am done testing it.

Tried to verify the fix on Win7/64 bit - Version 53.0.2785.24 (64-bit) & Version 54.0.2803.0 canary (64-bit).

Thank you Istiaque@ for providing the steps.

Steps Followed:

1. Installed the Application from CWS
https://chrome.google.com/webstore/detail/browser-sample/edggnmnajhcbhlnpjnogkjpghaikidaa
2. Launch the Application.
3. Go to chrome://inspect and go to tab Apps.
4. Click on Inspect of the Browser sample application.
5. Go to Console and execute the following:
var webview = document.querySelector('webview'); to grab the grab the existing webview

var webview = document.createElement('webview');
webview.setAttribute('id', 'player');
webview.setAttribute('partition', 'persist:player');
webview.setAttribute('src', 'http://refreshyourcache.com/en/cache-test/'); 
webview.addEventListener('contentload', () => {
 webview.clearData({}, { cache: true });
 webview.clearData({}, { cache: true });
});
document.body.appendChild(webview);

Please find the first attached screenshot.

6. call webview.reload() in the console to see that image is served from cache. Broken image is shown here. Please find the second attached screen shot.

7. Tried clearing the cache by calling clearData on the webview.

webview.clearData({since: 1}, {cache: true}, function() {console.log('cleared'); })

This returned true & cleared message is printed in the console.

8. Now call webview.reload() to see if the image is served from network.

I still see the broken image. Please find the attached last screen shot.

@Istiaque, can you please let me know if i have missed anything in the steps as i am not seeing the image being served from the network after clearing the cache.

Deleted: Step 1.PNG 137 KB

	Step 1.PNG 137 KB View Download

Deleted: Step 2 - Webview reload.PNG 154 KB

	Step 2 - Webview reload.PNG 154 KB View Download

Deleted: Webview Cache cleared.PNG 157 KB

	Webview Cache cleared.PNG 157 KB View Download

I'm not sure how that site is checking for cache and whether that's a reliable way, sigh (comment #16).

A better way is to check "Network" tab in developer tools.
Load the webview in same way as you are right now. Then in addition to the app's developer tools, also open the webview's developer tools. The latter can be done either by right clicking the webview (after it has loaded) and clicking inspect OR just open it through chrome://inspect, there should be a webview listed under the app.

Now once loaded, try calling webview.reload() few times and notice the network tab of the webview.
You should see (from cache) in the network tab's timeline column for lots of resources, pick one for example: "refresh-your-cache-logo.png", for context see [1]

Then you call webview.clearData...
then webview.reload()

You should see that the resource is not fetched from network. The (from cache) won't appear for the same resource where you've seen (from cache) before.

If you reload again, you'll see it getting served from cache again.

Hope this helps.

[1] http://www.ghacks.net/2014/08/11/find-out-if-websites-get-loaded-from-cache-and-how-to-force-reloads/

Issue 629142 has been merged into this issue.