Network stack / downloads status (vs FrameIOData)

[Charlie Reis]

Hi Charles, Nick, Randy, et al--

  I'd like to check in on the status of the network stack / download support for OOPIF, and what things we expect are currently broken.  Most importantly, Nick has mentioned that the FrameIOData work might not be necessary (or happening), so we should understand if that's a problem or if there are other ways to proceed.

  Nick, can you give a summary of your thoughts on FrameIOData?

  Charles/Randy, can you elaborate on what's left for updating the network stack, and what the blocking issues are?  Are any of them important issues for --isolate-extensions, or can they be addressed in a later stage?

Thanks!

Charlie

[Charles Harrison]

The major blocker is ResourceScheduler, which Randy is working on and has some detailed time estimates (check out the doc). 

Other than that, we populate the ResourceRequestInfo object with RVIDs, which some consumers use (notably, the host zoom map and webRequest API).

[Charles Harrison]

Randy, when you remove ResourceScheduler, do you have any need for frame-based data on the IO thread? I'm guessing no but I'm not completely sure.

[Randy Smith]

On Tue, May 17, 2016 at 11:05 AM, Charles Harrison <cshar...@google.com> wrote:

Randy, when you remove ResourceScheduler, do you have any need for frame-based data on the IO thread? I'm guessing no but I'm not completely sure.

Um ... yes, yes I do.  In fact, I'm inclined to say that because I need frame-based data on the IO thread, ResourceScheduler removal isn't relevant for the site isolation effort; there might be a period of time during which we wouldn't have to know what tab a request is associated with, but then we'll start needing that again. 

The basic issue if that if we want to do anything with prioritization per-tab, we need to know what tab a request is associated with.  I'm specifically looking at inter-tab prioritization (to deprioritize background tabs during startup or many-tab loads) after I get done removing the resource scheduler. That requires either going to the UI thread every time we need that information, or storing it in a per-frame data structure on the IO thread.  So if we're not doing anything about FrameIOData, that's a problem; I've made choices (specifically dropping the thread hop experiment on the floor) based on my understanding that that work was progressing.  

Why may it not be happening?

-- Randy

[Charles Harrison]

I think load state notifications can be frame based, I'll hack together a CL soon (I added creis@ as reviewer).

For resource priorities, this is hacky but what if ResourceRequestInfo just maintained the frame id of it's main frame? If this is just used for resource prioritization, it could work (I think there's some security implications if it's used for other things). To prevent misuse, could call it "main_frame_id_untrusted".

Adding davidben@ because we chatted about this today during lunch.

[Charles Harrison]

I'm also not sure what the plan is with webRequest API. I'm not sure what all its needs are.

[Nick Carter]

I posted this to the other thread; copying it here:

Regarding FrameIOData: I did some work on it last quarter, motivated by having an origin lock that worked better than what we have currently on ChildProcessSecurityPolicy. The more I've hacked on it, the more I've been discouraged that this design really solves the problem faced by the security policy use case: in particular, updating the origin lock for cross-site, non-transfer navigations is really tricky without browser-side navigation.

I can dust the patch off, but I'd need to have a new use case in mind we're convinced will actually fit for FrameIOData. For ResourceScheduler or load state notifications, what state do you want to be able to load/store for the RFH? Which IPCs are involved?

To recap: the idea of FrameIOData, as I conceive it, is: an IO thread object that is:

• scoped to the lifetime of the UI thread RFH (reliable cleanup / destruction)
  
• Retrievable and usable only on the IO thread, via a global routing id map
• available immediately after the routing ID is minted (i.e. RenderFrameMessageFilter::OnCreateChildFrame)

How would we want to use that?

[Charles Harrison]

For ResourceScheduler, we essentially tag requests with their associated RFID, and we want to group request on a per-tab basis on the IO thread without doing a thread hop per request.

For load state notifications, we want to iterate through all requests loading in a tab, pick the most "relevant one", and pass it to the WebContents layer for load state notifications (throbber, etc). This can be fixed to pass the most relevant load per frame to the WebContents, which then picks the most relevant load. I don't believe this should regress performance too much.

Also, as I eluded to above, I think webRequest uses an ad-hoc frame io data map already, so that probably needs to be fixed in some way. I'm not sure the plan there.

[Nick Carter]

I think for the most part my questions can be answered by what's already been said earlier. It sounds like you want to store a frameid->tabid mapping that's accessible on the IO thread, and used for prioritization?

I think that's straightforward except for the window.open case, where we see the rfh of the frame id created before the WebContents. So we'd need to do something there to obtain a tabid value to put in the FrameIOData (whatever value we get, we can forward as a param to the UI thread). Is there a particular existing tab identifier were you targeting for this?

Prerendering may also be a complication, depending on what behavior we need there.

[Randy Smith]

On Tue, May 17, 2016 at 1:57 PM, Nick Carter <ni...@chromium.org> wrote:

I think for the most part my questions can be answered by what's already been said earlier. It sounds like you want to store a frameid->tabid mapping that's accessible on the IO thread, and used for prioritization?

Yes, and from what Charles is saying, also for load state notifications (I don't know that code).

 

I think that's straightforward except for the window.open case, where we see the rfh of the frame id created before the WebContents. So we'd need to do something there to obtain a tabid value to put in the FrameIOData (whatever value we get, we can forward as a param to the UI thread). Is there a particular existing tab identifier were you targeting for this?

Nope; I don't think I care, as long as I can map it to/from a WebContents if I have to.  Main frame id would be fine. 

 

Prerendering may also be a complication, depending on what behavior we need there.

Do prerenders have a WebContents?  

-- Randy

[Charles Harrison]

What about the idea to just tag resource requests from the renderer with a main frame id? We already tag them with the parent frame's id. This would get us away from having to maintain the mapping.

[Randy Smith]

On Tue, May 17, 2016 at 2:06 PM, Charles Harrison <cshar...@google.com> wrote:

What about the idea to just tag resource requests from the renderer with a main frame id? We already tag them with the parent frame's id. This would get us away from having to maintain the mapping.

Huh.  We'd need to be careful that we didn't use that information for anything that's security-relevant, which makes it a slightly fragile plan.  Do renderers know their main frame id?  I'd sorta expect that they'd just know the parent.

Though truth to tell, if we have a whole lot of requests with both frame id and parent id, we can construct the frame tree ourselves.  That's effectively creating our own FrameIOData within the ResourceScheduler (+ whatever else needs the mapping), and has the same security concerns, but might be a reasonable fallback.

[Charles Harrison]

Some frames won't make requests, I think that's way too fragile.

Actually I think you're right. If the main frame is not in the same process I don't think it will exist. I think there's a couple places currently which make that assumption (I see a few TODOs from nasko@ about this). That's probably for the best, though not for ResourceScheduler :)

[Nick Carter]

Renderer processes never know routing ids of other processes.  Each renderer involved in a WebContents will have a routing id that represents the main frame, but it's a RenderFrameProxy route id for the subframe processes, and different for each process -- that's probably not really useful for grouping requests on the IO thread.

Also, the main frame id can change over the lifetime of a tab (but not the lifetime of a subframe). And two main frame ids can be alive at the same time for the same tab, as far as the network stack is concerned (e.g.  xhr from an unload handler during a cross process navigation).

If we want something consistent to use for grouping requests by tab, we've floated the idea of using the root frame tree node ID as a tab identifier, which is globally unique, and invariant over the lifetime of a WebContents. Corner cases are: interstitials (where we have a separate FrameTree for the overlay), webview tag (allows a webcontents to contain another as an html element, so there are effectively multiple roots per tab), and prerendering (where a tab swaps its webcontents with a prerendered graft).

[Randy Smith]

On Tue, May 17, 2016 at 2:33 PM, Nick Carter <ni...@chromium.org> wrote:

Renderer processes never know routing ids of other processes.  Each renderer involved in a WebContents will have a routing id that represents the main frame, but it's a RenderFrameProxy route id for the subframe processes, and different for each process -- that's probably not really useful for grouping requests on the IO thread.

Also, the main frame id can change over the lifetime of a tab (but not the lifetime of a subframe). And two main frame ids can be alive at the same time for the same tab, as far as the network stack is concerned (e.g.  xhr from an unload handler during a cross process navigation).

If we want something consistent to use for grouping requests by tab, we've floated the idea of using the root frame tree node ID as a tab identifier, which is globally unique, and invariant over the lifetime of a WebContents. Corner cases are: interstitials (where we have a separate FrameTree for the overlay), webview tag (allows a webcontents to contain another as an html element, so there are effectively multiple roots per tab), and prerendering (where a tab swaps its webcontents with a prerendered graft).

Root frame tree node ID sounds fine to me for prioritization and load state (though Charles is probably more on top of load state than I).  I don't think it matters for prioritization if interstitials are considered a separate tab, as long as it can be figured out (UI thread is fine) that they're the active tab.  Similarly for prerendering.  The webview tag sounds like a case where we do want to think of the two roots as being the same tab.

Are you planning to reach out to whoever's relevant for host zoom map and the webRequest API to confirm this solution works for their needs?   I think those are the other use cases that have been raised on this thread.

Thanks for looking into this ...