Sorry I messed up the title. It should be something along the lines of "Android WebView retains visited link list after clearHistory(), doesn't offer any other API to clear it".

Hmm, do we only have one AwBrowserContext per process? Then it seems strange to store visited-links in there.
Torne, do you have any thoughts here?

It's not weird to store it in AwBrowserContext - that's the WebView equivalent of Profile in Chrome, which is where the visited link history lives there, and in a browser-like app it's expected that visited links are global. The unexpected thing here is actually that killing the process will clear it - probably just because we haven't bothered implementing persisting it to disk. If we'd copied Chrome more closely here then even restarting the process wouldn't clear it, but our implementation relies on the embedding app to do this persistence if it wants it (which is why the ability to add things to the list exists).

I'm not sure clearing it when a single WebView's history is cleared makes sense; I think it'd be surprising to have a piece of global state be affected by a webview-specific call that never previously behaved that way. (do any CTS tests actually cover this behaviour closely enough to be affected?)

We should add a real API for this, but as you say that won't make it possible to clear it on existing OS versions; I think that since it's not written to disk this probably isn't enough of a privacy issue to justify a breaking behaviour change.

-

This also raises the more general fact that it's pretty hard to clear all browsing state in WebView - you have to call a bunch of different methods, there's no documented list of them, and even calling all of the ones that exist doesn't guarantee nothing else is retained (as this bug demonstrates). Maybe we should also have a single method to do this, equivalent to "clear browsing data" in Chrome? Though we'd still have to make sure everything was actually hooked up to it..

With all the clear and settings method on a WebView instance (as opposed to something like static methods on the class) I was expecting that this state is not shared between instances.

There's already a method (getVisitedHistory() in WebChromeClient) to backfill the cache for link coloring. So I do not agree that the "actual bug" is that this data is not persisted. Isn't keeping track of the history something for the application level and dependent on the use cases?

Regarding missing "clear" methods: We noticed this too. There's more data persisted (like service workers) that cannot be cleared via methods.

While I would like to see more options for clearing, I also fear that this would only be available for developers with a new Android versions and a WebView interface change?

Is there any path forward here?

WebView's API designs are not very consistent about what's the app's responsibility vs what's WebView's, unfortunately - this is a legacy of it being originally part of Browser and the split between what functionality was in WebView vs in Browser not being particularly well defined. For compatibility we're stuck with existing APIs working pretty much how they happen to work, in most cases (it's hard to prove that intentional behavioural changes aren't going to break existing app use cases). So, yes, you can point to lots of things that don't really make sense or aren't consistent, but.. that's just how it is. :/

You are correct that any improvements we make here are likely to only apply to new Android versions with a WebView interface change. However, we're trying to fix that situation as well: we're attempting to develop a support library that will give you access to some new APIs on older Android versions (back to L only), as long as the device has a new enough WebView version. If we're able to solve that then adding new APIs to deal with cases like this is more viable.

Moving new functionality in a support library sounds like a great plan (I guess this is another advantage of using Chrome as WebView provider?). I'm looking forward to it and hope it's not too far away. :-)

As link coloring is a visual indicator that the URL has been visited before: Wouldn't it be expected that the (already existing) clearHistory() method clears this memory cache that is responsible for link coloring too? Is this a fix that is also considered too risky and potentially breaking existing apps (Hard to imagine why an app requires link coloring without history)?

It's an advantage of the WebView being a separately updateable component; it doesn't have anything to do with Chrome.

As I said in earlier comments I don't think it makes sense to clear a piece of global state (visited link cache) when you ask to clear the history of one particular webview. There isn't a "clear all history" API in WebView right now; if there was then it would make sense for it to also clear the visited link cache.

> Maybe we should also have a single method to do this, equivalent to "clear browsing data" in Chrome? Though we'd still have to make sure everything was actually hooked up to it..

Reasonable suggestion. I think there may be value in fine-grained control (multiple clearFoo() APIs), and just request that apps call all of them (documentation is easy). Either way (one big API or multiple small APIs), we definitely should cover all things to clear.

I'm not sure that we can reasonably do that - Chrome doesn't really work this way, and so when new things are introduced I think we're likely to miss them. I would guess that our best chance of having reliable data-clearing APIs would be to imitate the Chrome "clear browsing data" feature as much as possible and reuse the plumbing in content, since that's more likely to do the right thing as the engine evolves. Our current different distinctions of what you can clear already don't match up with that, I think..

 ntfschr@, are you planning to add this functionality in the support library?

No, we cannot add APIs straight into the support library, they must first become android.webkit APIs. We have no definite plans to add an API for this.

---

Passing this to the pool of available bugs. This is probably a good API to add. Unfortunately, I don't think we have bandwidth to add such an API for P.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot