Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Problem/Bug]: CoreWebView2.AddWebResourceRequestedFilter("*", Document) doesn't work for secondary WebViews in the same process #4689

Open
Manish3177 opened this issue Jul 17, 2024 · 9 comments
Assignees
Labels
bug Something isn't working tracked We are tracking this work internally.

Comments

@Manish3177
Copy link

Manish3177 commented Jul 17, 2024

What happened?

We have an application where we want to inspect each frame-navigation and run some logic asynchronously to figure out if we want to allow that navigation. Failing that check, we want the iframe to stay on the page where the link was clicked. To achieve that, we first tried using the FrameNavigationStarting event whose args even have a Cancel property. The problem that made it not usable for us was that the args don't allow deferral so we couldn't run our asynchronous check.

As an alternative, we attempted using WebResourceRequested event which does support args.GetDeferral() method. We set up the following filters to intercept all navigation requests and some requests with a certain prefix:

		private void InitializeWebView2EventHandlers(...)
		{
			_webView.CoreWebView2.AddWebResourceRequestedFilter("*", CoreWebView2WebResourceContext.Document);
			_webView2.CoreWebView2.AddWebResourceRequestedFilter("prefix:*", CoreWebView2WebResourceContext.All);
			_webView.CoreWebView2.WebResourceRequested += CoreWebView2_WebResourceRequested;
		}

This works fine for the first WebView2 control we create on our main form of our application. We also create additional forms with new WebView2 controls and wire them up using the exact same code. However, the first filter does not work. Interestingly, the second filter does! I have tried changing the second parameter for first filter to All as well but it doesn't help.

Importance

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

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

126.0.2592.102

SDK Version

1.0.2535.41

Framework

Winforms

Operating System

Windows 11

OS Version

10.0.22631.3737

Repro steps

Steps to reproduce and relevant code is included in the problem description.

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#52931928

@Manish3177 Manish3177 added the bug Something isn't working label Jul 17, 2024
@Manish3177
Copy link
Author

Further testing shows that occasionally, the WebResourceRequested event fails to fire for the primary form as well. We have not been able to establish a pattern here. Perhaps this is really the same issue as #2341. However, that seems to indicate that the event never fires but, in our testing, it seems to fire about half of the times for the main window.

@yildirimcagri-msft
Copy link
Member

yildirimcagri-msft commented Jul 26, 2024

Hi, it seems your iframe may be a different origin, which would prevent you from getting WebResourceRequested event for such iframes. For this one, you'd need to use the AddWebResourceRequestedFilter with the SourceKind parameter overload

@Manish3177
Copy link
Author

Hi, thanks for the recommendation. Specifying ResourceSourceKinds.All for the third parameter seems to address the erratic behavior we were seeing on the primary form/WebView2 control. However, it doesn't help getting the event to fire on the secondary form/WebView2 controls. I tried with ResourceContext.All in addition to ResourceSourceKinds.All as well. To reiterate, on those forms, it fires for "prefix:" URLs just not for "anythingElse:". On the off chance that the bug was specific to "", I tried replacing the "" filter with "https://" and "http://" but that didn't work either.

To provide a little more information, we are intercepting the NewWindowRequested event, created a new form, and assigning args.NewWindow = newForm.WebView2Control.CoreWebWebView2.

@victorhuangwq victorhuangwq reopened this Jul 30, 2024
@yildirimcagri-msft yildirimcagri-msft added the tracked We are tracking this work internally. label Jul 30, 2024
@champnic
Copy link
Member

✅ Successfully linked to Azure Boards work item(s):

@Manish3177
Copy link
Author

Hi, It's good to see that a work item has been created for this. Is there any status update that can be shared?

@victorhuangwq
Copy link
Collaborator

We are currently looking into it; will keep you posted here if there's any updates

@yildirimcagri-msft
Copy link
Member

Hi @Manish3177 , when I try with our .NET sample app on an opened window with WebView2, I see the WebResourceRequested event fires for document when I add the filter as expected. For the opened window, are you registering the filter and WebResourceRequested event before or after you set the NewWindow property? In past we had some timing issues with the event not being registered on time for the first navigation of an opened WebView. Could you try changing the order you add the filter and the event to setting the NewWindow property to see if helps? You can try the following options:
-Register WebResourceRequested and filter before setting NewWindow property on NewWindowRequested.
-Register WebResourceRequested and filter aafter setting NewWindow property on NewWindowRequested but in the event handler.
-Register WebResourceRequested and filter on NavigationStarting handler of the NewWindow's first navigation. (This would miss the request for the first navigation)

@Manish3177
Copy link
Author

Manish3177 commented Sep 3, 2024

Hi Çağrı,

Our code currently attaches all event handlers, including the one for WebResourceRequested event, right after awaiting the call to webView.EnsureCoreWebView2Async. While we have not tried exactly what you are suggesting, we have tried attaching the event handler for WebResourceRequested on the first NavigationCompleted event firing. That helped a little bit in that, it was able to catch subsequent navigations of the top level window but it still didn't catch any navigations of iframes within that window. I will try to get a minimal repro app out to you sometime next week.

Ultimately, the event not firing reliably is a deal breaker for us. Even if it were to work 99% of the times on being attached in a strategic place, that would still not be good enough. Placing it in a very specific place seems fragile and inspires a feeling of uneasiness that it may not work under certain circumstances/configurations.

Despite some problems with [Frame]NavigationStarting events, since those are 100% reliable, I think we will implement our solution using those for now. The problems with those don't have as severe an impact. Also, we think we can find workarounds to those but not this problem.

@yildirimcagri-msft
Copy link
Member

Can you try adding the event handler and the filter after setting the NewWindow property as per NewWindow remarks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tracked We are tracking this work internally.
Projects
None yet
Development

No branches or pull requests

4 participants