FrameCreated is not called for iframe inside another iframe

[q71114]

Description FrameCreated is not called for iframe inside another iframe.

Version SDK: 1.0.1222-prerelease Runtime: Evergreen, 101.0.1210.39 Framework: WPF OS: Win11

Repro Steps

1. Added event handler to CoreWebView2.FrameCreated.
2. Open a website with nested iframes, for example this one.

Expectation: CoreWebView2.FrameCreated is raised for both iframes. Actual: Only one CoreWebView2.FrameCreated is raised (which is for the top level iframe).

AB#40114362

[champnic]

Thanks for the bug report @q71114, and sorry you are running into this. I've added this to our backlog to take a look. @vbryh-msft FYI.

[vbryh-msft]

Hi @q71114 FrameCreated event is raised currently only for top level iframes - this is known limitation. Could you please describe your scenario - why do you need nested iframes also and how are you going to use them. Thanks!

[q71114]

Hi @vbryh-msft, we need to be able to send / receive message from all iframes in order to monitor / pause / resume camera and microphone usage as currently this is the only way to do it. If this limitation with iframes could not be removed having this feature request implemented would be the next best thing if it can be extended with pausing / resuming the permission in use as well.

[vbryh-msft]

@q71114 are your nested iframes in the same origin as top level iframes/parent page - or they all can be different?

[q71114]

@vbryh-msft We need this to work with any setup so they can all be different.

[q71114]

Closed by mistake.

[perelmanari]

I would also like to a request for this feature.

We have an application using WebView2. Our users put enter a URL that they are in control of and we need to be able to read the contents of the webpage. One of our users has a webpage containing an iframe inside an iframe and we are unable to see it.

We would like to be able to work with nested frames the same way we work with top level frames. A nested frame could either trigger the CoreWebView2.FrameCreated or it could trigger a new CoreWebView2Frame.FrameCreated created.

Thank you

[Kay-Burchardt]

Please fix this issue ASAP.

[perelmanari]

Can we get an update on this? Is this something that you are planning on addressing? Is there any timeline?

Thank you

[vbryh-msft]

@perelmanari - sorry, there is no work currently in progress for this feature. Do you think we can come up with some workaround on JS side? I was thinking if you can use AddScriptToExecuteOnDocumentCreated which should work for nested and then use JS postMessage ?

[perelmanari]

Unfortunately, I don't think there is a workaround using Javascript. If a nested frame is cross-domain, then javascript wouldn't have access to it at all and interacting with cross-domain nested frames is exactly what I need to do.

[vbryh-msft]

Second linked doc says: The window.postMessage() method safely enables cross-origin communication - have you given it a try?

[perelmanari]

It would take a lot of javascript code and experimenting, but it seems like I could use a combination of those two to get a lot of functionality. I could detect document created and use that to know there is a new frame (FrameCreated) or an existing frame has navigated. Javascript could give me ReadyStateChanged events. I could use postMessage both directions to get similar functionality to ExecuteScriptAsync. Do you have any thoughts on how this could work to get NavigationStarting and WebResourceRequested events?

[perelmanari]

I have been experimenting using the devtools protocol to get events (Page.frameAttached, Page.frameDetached, Page.lifecycleEvent, Network.requestWillBeSent, Network.responseReceived, etc). Overall, this has been working well to achieve what I need. However, I am unable to get any events to fire on cross site frames.

This chromium bug report has information: https://bugs.chromium.org/p/chromium/issues/detail?id=924937#c13

I am able to use Target.setAutoAttached and get the Target.attachedToTarget event with the sessionId for the iframe. However, CoreWebView2.CallDevToolsProtocolMethodAsync does not have any way to pass a sessionId. It only allows for methodName and parametersAsJson.

Is there any way to do this currently with WebView2? Should I add a separate feature request to add an overload for CallDevToolsProtocolMethodAsync that accepts a sessionId?

[vbryh-msft]

Thank you for trying. We have method with sessionId input parameter - CallDevToolsProtocolMethodForSessionAsync

[perelmanari]

I can't believe I completely missed that method. Thank you.

[perelmanari]

Using that method, I am now able to see events from the cross site frames. I miss a few events due to async timing, but I can work around that. I think I will be able to get all the functionality I need this way.

Thank you for your help.

[nishitha-burman]

Hello, we are looking into this feature request and I have a follow up question: @q71114 do you know the hierarchy of the nested iframes? Thanks!

[q71114]

Hi @nishitha-burman,

Not sure I understood the question, but I used this example for testing so you can check out the hierarchy as needed.

[ynborokh]

Hi! Are there any news about this issue?

[MarkIngramUK]

Hello, we are looking into this feature request and I have a follow up question: @q71114 do you know the hierarchy of the nested iframes? Thanks!

We're building a browser, so need to support whatever hierarchy website creators implement (i.e. we have no idea what hierarchy to expect).

[wnayes]

Even if FrameNavigationStarting / FrameNavigationCompleted fire for all frames, it would be useful to fix this for the following reason:

FrameCreated is the only way to attach e.Frame.NavigationStarted / e.Frame.NavigationEnded, which are unique in that they receive CoreWebView2Frame as the sender. This lets you know the FrameId associated with with the navigation, which is helpful to keep track of which frames are doing which navigations.

(Of course, that use case could also be helped by providing FrameId on CoreWebView2NavigationStartingEventArgs / CoreWebView2NavigationCompletedEventArgs.)

[qkevin]

we need this as well