Lowering the priority because it's not as simple a fix as I originally thought.

Calling _webStateImpl->SetIsLoading(false) when repost warning is dismissed is not sufficient, because it results in the loading progress bar being animated, which can be misleading because no network load actually happened. This is caused by _webStateImpl->SetIsLoading(true) being called in -registerLoadRequestURL when reload first started. Ideally, that call should be skipped if the reload will result in a repost. But this information is not available then.

The real fix is to only call SetIsLoading in webView.isLoading KVO. This is tracked in crbug.com/767092.

It seems that this may not be a very common use case, since it only affects repost. Leaving it as RBS now, but P3, so if we can't get to it in time, maybe the RBS label can be dropped.

After https://chromium-review.googlesource.com/c/chromium/src/+/1243323, loading bar will be dismissed if user cancels, though it is still visible briefly. See attached screenshot.

I investigated the idea from comment #1. It turns out on reload, [CRWWebController -webViewLoadingStateDidChange] KVO callback triggers with |webView.loading| being true before the |webView:decidePolicyForNavigationAction| callback, which is where we display the repost confirmation. We can add special logic to try to ignore the |isLoading| KVO if we know the current request is a repost, but I'm not convinced that it's worth the trouble.

eugenebut@: do you think the current fix is acceptable?

Deleted: crbug865972_fix_demo.mov 751 KB

	crbug865972_fix_demo.mov 751 KB View Download

Thanks Danyao! I think the current fix is totally acceptable. There are quite a few cases where Chrome briefly shows toolbar progress for no good reason, and I feel like form repost is more like an edge case.

Excellent! Thanks for confirming. :)

Verified in:

App Version: 71.0.3567.0 canary
Devices: iPad Air, iPhone 8 Plus
iOS Version: 11.4.1, 12.1 beta 1

Loading progress bar is dismissed when repost warning is cancelled