Difference between mojo interfaces Frame and FrameNavigationControl?

[Ian Barkley-Yeung]

What's the difference between the mojo interfaces Frame and FrameNavigationControl (both in content/common/frame.mojom)? 

I'm trying to add a new function to one of them, and I'm trying to figure out which one is the correct one. They are both implemented by the same class (RenderFrameImpl), so there doesn't seem to be an obvious technical reason to prefer one to the other.

For more context:

The specific function I want to add  (called something like SetWantErrorMessageStackTrace) will have two effects: Causing RenderFrameImpl::ShouldReportDetailedMessageForSource to return true in more cases, and calling v8::Isolate::SetCaptureStackTraceForUncaughtExceptions(). Since I'm calling a v8 function, and since the functions that "do something with JavaScript" (like JavaScriptMethodExecuteRequest) are in FrameNavigationControl, I am planning to put the function in FrameNavigationControl, but I'm not really sure that's correct because I don't actually understand why the JavaScript functions are in one instead of the other. 

Thanks for any advice!

[Alexander Timin]

+navigation-dev 

The main difference here is the ordering — Frame interface uses mojo::Receiver, while FrameNavigationControl uses mojo::AssociatedReceiver.

That means that messages send via FrameNavigationControl are sharing a mojo pipe and guaranteed to be ordered with regard to other navigation-associated messages (e.g. navigation commit, devtools messages, postMessage and more), while Frame interface gets a dedicated mojo pipe and messages sent via it can be reordered w.r.t. all other mojo messages.

So the question here is whether you need this ordering, which leads to the question of who and when will call your new method on the browser side.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/d42efb10-b54a-4907-bb6d-183478871692n%40chromium.org.

[dan...@chromium.org]

On Wed, Nov 25, 2020 at 1:56 PM Alexander Timin <alt...@chromium.org> wrote:

+navigation-dev 

The main difference here is the ordering — Frame interface uses mojo::Receiver, while FrameNavigationControl uses mojo::AssociatedReceiver.

That means that messages send via FrameNavigationControl are sharing a mojo pipe and guaranteed to be ordered with regard to other navigation-associated messages (e.g. navigation commit, devtools messages, postMessage and more), while Frame interface gets a dedicated mojo pipe and messages sent via it can be reordered w.r.t. all other mojo messages.

So the question here is whether you need this ordering, which leads to the question of who and when will call your new method on the browser side.

Perhaps it would help to understand why any message would not want to be ordered relative to other messages arriving in RenderFrameImpl. That seems quite hazardous, and I would love to understand that more. And maybe that would help explain where to place an IPC as well.

Thanks,

Dana

 

On Mon, 23 Nov 2020 at 20:05, Ian Barkley-Yeung <i...@chromium.org> wrote:

What's the difference between the mojo interfaces Frame and FrameNavigationControl (both in content/common/frame.mojom)? 

I'm trying to add a new function to one of them, and I'm trying to figure out which one is the correct one. They are both implemented by the same class (RenderFrameImpl), so there doesn't seem to be an obvious technical reason to prefer one to the other.

For more context:

The specific function I want to add  (called something like SetWantErrorMessageStackTrace) will have two effects: Causing RenderFrameImpl::ShouldReportDetailedMessageForSource to return true in more cases, and calling v8::Isolate::SetCaptureStackTraceForUncaughtExceptions(). Since I'm calling a v8 function, and since the functions that "do something with JavaScript" (like JavaScriptMethodExecuteRequest) are in FrameNavigationControl, I am planning to put the function in FrameNavigationControl, but I'm not really sure that's correct because I don't actually understand why the JavaScript functions are in one instead of the other. 

Thanks for any advice!

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/d42efb10-b54a-4907-bb6d-183478871692n%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CALHg4nkG8weV99_3EvTWAxjvNu3yvWAm1LNXNxKKD%2B5SdcMUow%40mail.gmail.com.

[Daniel Cheng]

FWIW, I think having Frame vs FrameNavigationControl was a mistake. Frame is already a fairly small interface; we should just fold into FrameNavigationControl, remove Frame, and rename FrameNavigationControl. IIRC, the Blink frame interfaces don't bother with this distinction.

Daniel

You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CALHg4nkG8weV99_3EvTWAxjvNu3yvWAm1LNXNxKKD%2B5SdcMUow%40mail.gmail.com.

[Dave Tapuska]

1) content::mojom::Frame and content::mojom::FrameNavigationControl pre-date any blink::mojom::Frame interfaces

2) I believe content::mojom::Frame tried to take things that didn't have scheduling ordering problems with, but that really just complicates things and doesn't really yield much benefit.

3) it was clear for a number of these messages they were dependent on other messages so it was impossible to further tease more of them apart into content::mojom::Frame.

4) If you can add things directly to blink::mojom::Frame interfaces that is definitely preferred (not sure if it is applicable for the messages you are looking at adding though).

Onion Soup's eventual goal is to remove most of content/renderer so it means these content::mojom:: interfaces will eventually be rolled into blink ones.

dave.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAF3XrKoradtUjkJrx_mE1dh8TxreyGihBO0KrvEey99wJPj%3DRQ%40mail.gmail.com.

[Ian Barkley-Yeung]

Are there any gotchas with regards to use of FrameNavigationControl, particularly around using it early in the browser's life?

Details are in https://chromium-review.googlesource.com/c/chromium/src/+/2556008?tab=comments, but basically, I put my new function in FrameNavigationControl and tried to call it (from the WebUI constructor) while restoring a page as part of a "Continue where you left off". In that case, the chrome://flags page gets messed up and loses all dynamic content. This only happens as part of "Continue where you left off" -- if I open a new tab and navigate to chrome://flags, it works fine, and if I add a short delay (by just posting a task which does the same thing), it works fine.

Anyone know why that might be?

[dan...@chromium.org]

On Wed, Nov 25, 2020 at 6:40 PM Ian Barkley-Yeung <i...@chromium.org> wrote:

Are there any gotchas with regards to use of FrameNavigationControl, particularly around using it early in the browser's life?

Details are in https://chromium-review.googlesource.com/c/chromium/src/+/2556008?tab=comments, but basically, I put my new function in FrameNavigationControl and tried to call it (from the WebUI constructor) while restoring a page as part of a "Continue where you left off". In that case, the chrome://flags page gets messed up and loses all dynamic content. This only happens as part of "Continue where you left off" -- if I open a new tab and navigate to chrome://flags, it works fine, and if I add a short delay (by just posting a task which does the same thing), it works fine.

Anyone know why that might be?

I'm guessing you want to wait for the frame to finish loading before mutating it, else you're racing with the renderer? https://source.chromium.org/chromium/chromium/src/+/master:content/public/browser/web_contents_observer.h;drc=07d8a26d41639844ab51ea02433053a1b5e38297;l=150

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAPHpbpSTrd3MH9sdz%3DaDrSUTXxLhnnh6BZ%2BHdODP%2B2Ti1oVZxw%40mail.gmail.com.

[Ian Barkley-Yeung]

Looking at this a little closer, it's not sending the message that breaks things, it's getting the interface. That is, just calling RenderFrameHostImpl::GetNavigationControl() is enough to break the connection. 

> I'm guessing you want to wait for the frame to finish loading before mutating it, else you're racing with the renderer?

I don't want to wait for it to finish loading, because I want stacks for any JavaScript errors that happen during load. But I want to wait for the frame to finish... setting up, maybe? 

As an experiment, I had the message delayed until RenderFrameHostImpl::IsRenderFrameCreated() returns true. This seems to fix the problem. I don't completely understand the details of the lifecycle; does this sound right? If no one objects, that's what I'll go with.