Questions for some content folks:

1) Can ResourceRequestInfo::GetFrameTreeNodeId() be modified to also return the correct FTNId for the requesting frame of a subresource request. Currently it returns -1 for all non-PlzNavigate requests. Is the reason it doesn't already do so just because it needs plumbing through the ResourceDispatcherHost or is this some design choice?

If we can return the correct FTNId for subresource loads, we might be able to eliminate ExtensionFrameIDMap by
  - Maintaining a map from FTNId => FrameData on the IO thread. This can be populated from the navigation UI data on observing a navigation request.
  - For a subresource request, we can get the FTNID using ResourceRequestInfo and then use the FrameData we have.
  - Delete entries whenever the frame tree node is destroyed (using FrameTreeNode::Observer?)
  - What can cause the FrameData (frame_id, parent_frame_id, tab_id, window_id) for a frame/FTN to change? (Tab being reparented is one case).
  - Orthogonal to this, I was looking to also add the top level frame url to the FrameData. Ignoring same-document navigations, does the top level frame URL for a frame/FTN stay constant during a frame's lifetime?

2) Alternatively, can we introduce a copyable interface similar to NavigationUIData, say RequestFrameUIData for subresource requests, that is initialized on the UI thread and and later used on the IO thread? It can take in a RenderFrameHost (corresponding to the requesting frame) and content embedders can initialize any data they see fit on the UI thread pertaining to the requesting frame. It can then be accessed through ResourceRequestInfo.

1) This is hard to do in the current state of the code, in particular since we're heavily refactoring the network stack and how it interacts with content as part of the network service. I think if we want to invest in a solution, it should be one that works with the network service.

2) No: requests are received on the IO thread. If we wanted to initialize this struct on the UI thread, we'd have to block every single subresource request on a round-trip to the UI thread. This is strictly worse than blocking 0.2% of the time.

More generally, as explained in 1), this area of the code is changing due to the network service happening. Do you already have a plan in place for how WebURLRequest will be supported in the network service world? If not, this is where we should start. If that plan is there and still relies on the ExtensionAPIFrameIdMap, then we can have a look at eliminating it, we might be easier to do in a network service world by relying on subresource URLLoaderFactories.

+jam for network service related questions.

cc: rockot@ who is working on supporting web request API with network service. Ken, can you look at the bug and elaborate a bit on how will constructs like FrameData (associating network requests with render frames) look in a network-service world. Would constructs like ExtensionAPIFrameIDMap no longer be needed?

Right, anything which exists for the sole purpose of duplicating UI-thread
data on the IO-thread (which seems to be the point of
ExtensionAPIFrameIDMap) should disappear. In general once the network stack
is moved off the IO thread there are really no legitimate reasons for
extensions to be doing work there.

Sounds good, will close this then.