Ugggh. Okay, so reading through the code and bug conversation I can immediately see why we introduced this leak: we concluded in the previous bug that it didn't make sense for the headers not to be reused on forward/back navigation (even though that was the old behaviour). This means the headers *have* to outlive the current pageload, or else they can't be used again later.

So, we could:

1) Try to find some way to tie the saved headers to the navigation entry instead of being global. This would preserve all the current behaviours, but mean that if you deleted the WebView instance the headers would get freed when the navigation stack was deleted. (side point: currently saveState/restoreState doesn't preserve these headers... perhaps it should if we believe the argument about consistency from the previous bug? but the state is already too big..)

2) Just decide the previous decision was wrong and it's fine if forward/back navigations don't reuse the headers. There's probably some way to clean it up after the load completes if we do that, and then they'll live for a pretty short period of time. No idea if anyone actually cares about the behaviour here or not, but since the old webview did this it's probably *fairly* safe still?

3) Decide the whole design here is weird and that it's okay to apply the headers to all the subresource loads as well, which I think is what Bo is wondering about above. I don't think this is desirable - while yes there are people who want to add headers to all requests, they actually mean *all* requests in their use cases, I think: i.e. things initiated by XMLHttpRequest or fetch, or generally any weird case you can think of, not just subresources of the page you call loadUrl on. What most/all of those use cases want is the ability to mangle headers in shouldInterceptRequest instead.

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