[Problem/Bug]: When [Frame]NavigationStarting event handler runs, args.Request.Headers never has Referer header

[Manish3177]

What happened?

When [Frame]NavigationStarting event handler runs, args.Request.Headers doesn't have the Referer header even if the actual request to the target URL has it. Specifically, args.Request.Headers.Contains("Referer") returns false. We have some logic in [Frame]NavigationStarting event handler that uses the Referer header to decide (a) whether to set args.Cancel = true and (b) whether to a UI (MessageBox) to the user indicating that the navigation was cancelled.

This is particularly odd given that the request is dispatched before the event handler actually runs as noted in #4765. Also, for what it's worth, the header is present in the WebResourceRequested event handler but we are unable to use because it's unreliable as noted in #4689.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

127.0.2651.105

SDK Version

1.0.2535.41

Framework

Winforms

Operating System

Windows 11

OS Version

10.0.22631.4037

Repro steps

Set up a [Frame]NavigationStarting event handler to record/log the value of args.Request.Headers.Contains("Referer"). Attempt a few navigations while recording network traffic with dev tools or Fiddler. Observe the recorded/logged value is always false even if some navigations have the Referer header.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

AB#53476110

[yildirimcagri-msft]

We added this to our backlog, but this may not be a simple fix because Chromium network stack adds such headers as Referrer after the navigation event is reported to us. Ideally, you can also use WebResourceRequested event for this.

[Manish3177]

Hi Çağrı, Thanks for the update. I wanted to mention an alternative solution if it will be relatively easier to implement. If #4604 was addressed by providing a FrameInfo property of type CoreWebView2FrameInfo on NavigationStartingEventArgs, then we can access args.FrameInfo.ParentFrameInfo.Source to get something equivalent. I realize that's not exactly the same thing but from a user point of view that may actually work better. Also, there is a potential problem with "Referer" header that it will likely be susceptible to breaking if the parent website specifies Referrer-Policy as no-referrer. We are not too worried about that but the alternative solution is likely not going to be affected by that.