Details
P1: Critical Description
Description
In 5.10.0 when you would reset the QWebEngineUrlInterceptor on a profile with QWebEngineProfile::setRequestInterceptor all new requests would immediately start being routed to the new interceptor. In 5.15.0 the behavior has changed (for both setRequestInterceptor and its replacement setUrlRequestInterceptor) - depending on what you do afterwards requests inconsistently will or will not be routed to the replacement interceptor. This is also the case for QWebEnginePage::setUrlRequestInterceptor.
There's more information in the Repro steps but it appears that a call to QWebEnginePage::Load is necessary to recognize the new interceptor, but even then some requests may be routed to the old interceptor. I expect some of this may be due to async issues but I see no mention in the documentation of this as a concern. That you cannot replace the router without calling Load seems like strictly a bug though (or at least should be documented).
Repro
See attached project. When you click "Hit Demo" it will install a simple interceptor on the profile (though it also repros if installed on the page) to count requested urls and then load a simple page. Once that page initially loads it will install a second interceptor. Then, depending on your checkbox, it will either reload the page or just make a request using fetch. Both display behavior different than the 5.10 behavior. Note that this application is pretty quick and dirty - it doesn't do any clean up so best to only run it once.
Reloading page:
The initial request hits the first interceptor but then after installing the interceptor a request from that initial page still gets routed to the old interceptor. The actually reloaded page's requests all go to the second interceptor.
Fetching a new url:
All requests continue to go to the original interceptor - no requests are intercepted by the replacement.
Workarounds
None that I've found.