Sorry, I'm currently not working on iOS issues

This seems to be a Navigation History Issue not related to the History UI (Which is cleared after CBD)
eugenbut@ WDYT?

This is not related to history UI, but rather to clearing browsing data. https://crrev.com/796851 fixed the bug for Desktop and Android, but nothing was done for iOS. 


Martin, is this something that your team can take?

Clearing browser data in iOS today involves deleting the WKWebView. With go/bling-navigation-experiment, I actually have to add special logic to make sure navigation history of the tab is NOT deleted. This is a source of complexity and bugs because it uses the client-side restore logic. If user actually wants to see the navigation history cleared, we can delete the special logic and it'll be an overall tech debt win for iOS.

I think that "Cached Images and Files" deletion also deletes WKWebView. But clearing cashes should not remove back-forward navigation history.

Ah OK. If we can differentiate between these two cases in Bling's code and only restore history in clearing cache case, that would be nice.

We could move cookie clearing code to ios/web layer ( crbug.com/884341 ). In that case ios/web could differentiate between different types of cleared data.

So to summarize my understanding: WKWebView already automatically deletes navigation history when some datatypes are deleted. We have a code in Chrome which restores it. We want to remove that code from the history deletion codepath. We don't want to remove that code from cache deletion codepath.

Is that correct?

Re #4, I'm happy to put this on our roadmap, given that our team owned this on Desktop and Android too.

Comment #9 sounds like a great summary. If we follow this approach we will diverge from /content implementation, but that's probably fine given that solution will be much cleaned for iOS.