One challenge that Josh Karlin and I ran into, which is not possible to solve in the browser process today, is that documents in subframes can in some cases be created without a corresponding navigation. Various code in the browser process today, such as page load metrics code, assumes that the commit of a navigation is the point at which a document is created. Unfortunately, this isn't true in cases where a document is created in a child frame via JS.

One such example is covered in a browsertest that Josh Karlin wrote: https://cs.chromium.org/chromium/src/chrome/test/data/ads_observer/docwrite_provisional_frame.html?q=docwrite_provisional_frame&dr

Josh has code that wants to track information associated with a document in a frame, but since the document in this test is created w/o a navigation ever committing in that frame, it's impossible to know with certainty that there's an active document in the frame from the browser process, given current APIs available in the browser process. Josh's code has to work around this using heuristics which happen to work for his use case and are somewhat fragile. It would be better to have explicit APIs to notify about creation and destruction of documents hosted in frames.

Adding dcheng@, as he has been proposing for a while that we swap RenderFrameHost on each navigation that results in a new document. That will make document:RFH be a 1:1 relationship. It has a lot of appealing properties, but it likely also has some perf hit. If anyone is interested in experimenting with making it work, please chime in.

Interesting, thanks!

Could we also swap RFH in cases where a new document is created w/o a corresponding navigation, such as in this example: https://cs.chromium.org/chromium/src/chrome/test/data/ads_observer/docwrite_provisional_frame.html?q=docwrite_provisional_frame&dr

#3: The document.open case is definitely an interesting one.  Even without a document abstraction in the browser process, we may want to give the browser process a notification when it changes.  (It can affect the URL of an about:blank page as well, as in issue 466422.)

But yes, we're considering having a document abstraction, whether that's RenderFrameHost or changing it into something like a RenderDocumentHost.  document.write is a good test case for any possible design there, since we'll need to think about what *doesn't* change in the frame in that case, and what might break if we switched RenderFrameHosts in that case.  We haven't thought about it carefully yet.

And since this bug is collecting use cases, we've also discussed having a browser process abstraction for documents in order to improve how we do permission checks in a Mojo/servicification world.

Thanks for adding. Comment #1 is interesting in particular, as I was making similar assumptions in some ongoing work regarding the lifetime of documents being tied to navigation commits (oops.)

How does that work from the browser's perspective? i.e. if a subframe is navigated to foo.com/bar and then its contents are replaced with a new document via script in the main frame, presumably the last-committed URL for the subframe (from the browser's perspective) is still foo.com/bar, despite that URL no longer having any relevance to the frame's contents. Is that accurate?

What is the security origin of a frame whose document was constructed dynamically by script in another frame? Presumably it can't be anything other than the origin of the frame which did the scripting. But how is that conveyed to or understood by the browser?

I think we could try to make it work (e.g. swap) for the document.open case, but it might be tricky.

Re comment #6: I believe your understanding WRT document.open is correct. On the renderer side, the Document's URL is the "responsible document"'s URL, per https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open (note that this spec for document.open is pretty out of sync with what's actually implemented). Since we don't update the browser side, the browser side URL will be out of sync.

The origin is the security origin of the "requesting Document" as well... I think. The spec is pretty hard to parse.

Nasko and I met a few weeks ago to discuss the idea of swapping the RFH as well as adding a document identifer.

Nasko's notes from our chat:
* Document id is useful still even with RFH per navigation - handles the document.write case
* document.open() might be ok to make slower for a sync IPC to get a globally unique id [from the browser process]
* WCO::DidCreateDocument sending the doc ID, WCO::DidFinishNavigation also gives the doc id that was result from the navigation. 
* WCO loading callbacks can get a doc id, so they can easily correlate loading of documents
* Actually, DidStart/FinishNavigation can also satisfy the [doc.open] new doc case, and emulate it the same way we do for same-document navigation, which means no need for WCO::DidCreateDocument
* For IPCs, even with RFH per doc, do we need to send doc ID?

For clarity: it would still not be possible to create a discrepancy between the *origin* of last-committed URL and that of the actual document, right?

I believe so. I had initially thought it was possible for a parent frame to change a child frame's origin via document.open/document.write, but Nasko explained to me that parent frames can't call document.open, etc on cross-origin children. So I believe it should be reasonable to assume that the document's origin will always be the same as the origin of the last commit in that frame. Others on this bug can say for sure, though.

We don't seem to be replacing the Document instance in response to `document.open`. In the edge case where there hasn't been a real load yet in the frame, we seem to re-use the initial empty Document.

Crazy idea: Could we just simply synthesize a (synchronous) navigation in this case?

Even crazier idea: From 10000 feet, this looks pretty similar to what we classify today as a same-document navigation. For example, history.pushState already allows changing the document URL to whatever as long as it is same-origin. Compared to that, the only regression here would be the introduction of "same-document navigations" from about:blank to not, while the origin remains the same. Interestingly, document.open does not seem to respect document.domain either, although I'm not sure if this is intended.

I suppose there are other weird scenarios I am totally unaware of? :)

On second thought, I guess we don't want make a document.write-triggered synthesized navigation same-document if there hasn't been any real committed load yet, so for consistency we might not want to do that at all?

Those are great suggestions, and pretty consistent with what Nasko and I discussed when we met about this a few weeks ago:

* document.open() might be ok to make slower for a sync IPC to get a globally unique id [from the browser process]
* WCO loading callbacks can get a doc id, so they can easily correlate loading of documents
* DidStart/FinishNavigation can also satisfy the [doc.open] new doc case, and emulate it the same way we do for same-document navigation, which means no need for WCO::DidCreateDocument

I think there's high level agreement that something like this makes sense, but nobody has stepped up to implement it yet.

There's a lot of issues with document.open() and document.write(): different browsers implement different behaviors today.
- document.open() doesn't give you a new Document.
- but it's supposed to give you a new Window object (though this only happens in Firefox)
- similarly, document.open() also says it fires unload events (which also only happens in Firefox, IIRC)
- so on and so forth.

In fact, there's some spec discussion to resolve these issues: https://github.com/whatwg/html/issues/1698

However, taking a step back, why does the browser process need to know about document.open()? It's not really a navigation today in Blink: you can't navigate back or forward from it (incidentally, you can do this in Firefox, though it seems to be a point of active debate whether or not we should do this). The Document object itself doesn't change, so per the 1:1 model of Document:Frame, I would have initially imaged that we just keep the objects the same, and just change the document URL.

Sure, good questions. There are a few cases where we want to be able to discover the existence of documents created via document.open in the browser.

One is Josh Karlin's ads metrics component. His code wants to track information about resources loaded by a document. He encountered a case which some real ads libraries exercise where a frame is created with an initial provisional nav, and before that nav commits, the parent frame doc.open/doc.writes into the frame, canceling the nav and replacing its contents with a new document. Josh's code wants to know about that document being created, but the navigation APIs in the browser process only report that a provisional nav started and then that it failed, with no indication that there is now a valid document in that frame. The ads metrics tracking code then starts seeing resources being loaded in that frame and gets confused because as far as it knows there's no valid committed document in that frame.

Josh had to make up some heuristics to work around this but we were pretty unhappy with them and would rather receive a notification that a document was created in the frame.

Here's a test case Josh wrote for this particular case:
https://cs.chromium.org/chromium/src/chrome/test/data/ads_observer/docwrite_provisional_frame.html?q=docwrite_provisional_frame&dr

Another case is page load metrics code more generally. Page load metrics tracked in the render process are scoped to a document, and then sent to the browser process where it's recorded as being associated with the most recently committed navigation. When a document is replaced via document.open/document.write, however, the browser-side page load metrics code gets confused, because it starts getting new metrics for that new document, but never learned there was a new document created. Here, too, knowing that a new document was created would help us to correctly handle this case.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6a0d424c8d2acd68af77d9f7450754f6cc628e7c

commit 6a0d424c8d2acd68af77d9f7450754f6cc628e7c
Author: Balazs Engedy <engedy@chromium.org>
Date: Tue Aug 01 11:38:42 2017

Make FrameDetached_WindowOpenIPCFails robust.

The test used to schedule a call to window.close() in the main frame of
a WebContents to close itself after it calls window.open().

However, the CreateNewWindow sync IPC could still have been dispatched
*before* ViewHostMsg_Close in the browser process in the unfortunate
scenario where the browser process happened to be waiting for a reply to
another sync IPC on the UI thread, in which case incoming sync IPCs to
this thread are dispatched, but the message loop is not pumped, so
proxied non-sync IPCs such as ViewHostMsg_Close are not delivered.

This CL remedies the problem by triggering window.open() just before the
FrameMsg_Delete messages would be sent to the frame.

Bug: 728171, 729021
Change-Id: Ia2d53447d58e4038d2ceafdf8b2d70ed8c7d494d
Reviewed-on: https://chromium-review.googlesource.com/589273
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490944}
[modify] https://crrev.com/6a0d424c8d2acd68af77d9f7450754f6cc628e7c/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[add] https://crrev.com/6a0d424c8d2acd68af77d9f7450754f6cc628e7c/content/test/data/render_frame_host/window_open.html
[delete] https://crrev.com/41ee49fe74f4a8a3b9a23269a00c141237d4647e/content/test/data/render_frame_host/window_open_and_close.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/58f640339c3f89f530251d85723041583febb5b3

commit 58f640339c3f89f530251d85723041583febb5b3
Author: Balazs Engedy <engedy@chromium.org>
Date: Wed Aug 09 17:42:33 2017

Refactor ChromeRenderViewTest.JSBlockSentAfterPageLoad

Make the test not depend on DidCommitProvisionalLoad being an IPC message.
This is in preparation for Mojofying FrameHostMsg_DidCommitProvisionalLoad.

Bug: 729021
Change-Id: I978b0c44a5f8189d5047962aad1e1340374ddb4b
Reviewed-on: https://chromium-review.googlesource.com/607507
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493044}
[modify] https://crrev.com/58f640339c3f89f530251d85723041583febb5b3/chrome/renderer/content_settings_observer_browsertest.cc
[modify] https://crrev.com/58f640339c3f89f530251d85723041583febb5b3/content/public/test/render_view_test.cc
[modify] https://crrev.com/58f640339c3f89f530251d85723041583febb5b3/content/public/test/render_view_test.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa8adf8fea6dd127158b9e98984338cf73970b4e

commit fa8adf8fea6dd127158b9e98984338cf73970b4e
Author: Balazs Engedy <engedy@chromium.org>
Date: Thu Sep 07 14:06:27 2017

Mojofy DidCommitProvisionalLoad.

Refactor FrameHostMsg_DidCommitProvisionalLoad from being a legacy
IPC message into a method on mojom::FrameHost, a frame-scoped,
Channel-associated interface. There is no change to functionality.

Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I794a8f1cb433a82e2c1d9351630116b584f8fcf9
Reviewed-on: https://chromium-review.googlesource.com/607607
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500294}
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/frame_host/navigator_impl_unittest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/loader/resource_scheduler_filter.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/loader/resource_scheduler_filter.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/browser/security_exploit_browsertest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/BUILD.gn
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/frame.mojom
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/frame_messages.h
[add] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/frame_messages.typemap
[add] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/frame_messages_forward.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/navigation_params.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/common/typemaps.gni
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/public/test/test_renderer_host.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/renderer/render_frame_impl.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/renderer/render_view_browsertest.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/renderer/render_view_impl.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/BUILD.gn
[add] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/did_commit_provisional_load_interceptor.cc
[add] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/did_commit_provisional_load_interceptor.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/test_render_frame.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/test_render_frame.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/content/test/test_render_frame_host.cc
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/extensions/common/extension_messages.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/mojo/public/cpp/bindings/associated_binding.h
[modify] https://crrev.com/fa8adf8fea6dd127158b9e98984338cf73970b4e/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19

commit e0d59a3c97c02ff04f860a0aff4b5feb9b985d19
Author: Roger McFarlane <rogerm@chromium.org>
Date: Thu Sep 07 15:41:54 2017

Revert "Mojofy DidCommitProvisionalLoad."

This reverts commit fa8adf8fea6dd127158b9e98984338cf73970b4e.

Reason for revert:

Seeing new Win10 failures in navigation_controller_impl_browsertest.cc post this commit. 

Original change's description:
> Mojofy DidCommitProvisionalLoad.
> 
> Refactor FrameHostMsg_DidCommitProvisionalLoad from being a legacy
> IPC message into a method on mojom::FrameHost, a frame-scoped,
> Channel-associated interface. There is no change to functionality.
> 
> Bug: 729021
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
> Change-Id: I794a8f1cb433a82e2c1d9351630116b584f8fcf9
> Reviewed-on: https://chromium-review.googlesource.com/607607
> Commit-Queue: Balazs Engedy <engedy@chromium.org>
> Reviewed-by: Alexander Timin <altimin@chromium.org>
> Reviewed-by: Ken Rockot <rockot@chromium.org>
> Reviewed-by: Nasko Oskov <nasko@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#500294}

TBR=dcheng@chromium.org,nasko@chromium.org,rockot@chromium.org,engedy@chromium.org,altimin@chromium.org

Change-Id: I2d8798575907a7d195e65ee2bc9fd49e190f84f9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Reviewed-on: https://chromium-review.googlesource.com/655142
Reviewed-by: Roger McFarlane <rogerm@chromium.org>
Commit-Queue: Roger McFarlane <rogerm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500308}
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/frame_host/navigator_impl_unittest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/loader/resource_scheduler_filter.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/loader/resource_scheduler_filter.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/browser/security_exploit_browsertest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/common/BUILD.gn
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/common/frame.mojom
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/common/frame_messages.h
[delete] https://crrev.com/27dd5a5bdafcdfdb630f19b071ec6fb54cb3bd89/content/common/frame_messages.typemap
[delete] https://crrev.com/27dd5a5bdafcdfdb630f19b071ec6fb54cb3bd89/content/common/frame_messages_forward.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/common/navigation_params.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/common/typemaps.gni
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/public/test/test_renderer_host.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/renderer/render_frame_impl.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/renderer/render_view_browsertest.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/renderer/render_view_impl.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/test/BUILD.gn
[delete] https://crrev.com/27dd5a5bdafcdfdb630f19b071ec6fb54cb3bd89/content/test/did_commit_provisional_load_interceptor.cc
[delete] https://crrev.com/27dd5a5bdafcdfdb630f19b071ec6fb54cb3bd89/content/test/did_commit_provisional_load_interceptor.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/test/test_render_frame.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/test/test_render_frame.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/content/test/test_render_frame_host.cc
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/extensions/common/extension_messages.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/mojo/public/cpp/bindings/associated_binding.h
[modify] https://crrev.com/e0d59a3c97c02ff04f860a0aff4b5feb9b985d19/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a40712f84aed485b3da6d212938e330ae3b85605

commit a40712f84aed485b3da6d212938e330ae3b85605
Author: Balazs Engedy <engedy@chromium.org>
Date: Fri Sep 15 15:01:11 2017

Mojofy DidCommitProvisionalLoad.

Refactor FrameHostMsg_DidCommitProvisionalLoad from being a legacy IPC
message into a method on mojom::FrameHost, a frame-scoped,
Channel-associated interface. There is no change to functionality.

This is a reland of crrev.com/500294, now that the reentrancy issue in
GpuChannelHost::Send has been resolved by crrev.com/502124. TBR'ing
original reviewers.

TBR=altimin@chromium.org,rockot@chromium.org,nasko@chromium.org

Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ic5bd3e1a69c8d4b7a58ae843ccbfe0e6d6241db4
Reviewed-on: https://chromium-review.googlesource.com/667115
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502254}
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/frame_host/navigator_impl_unittest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/loader/resource_scheduler_filter.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/loader/resource_scheduler_filter.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/browser/security_exploit_browsertest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/BUILD.gn
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/frame.mojom
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/frame_messages.h
[add] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/frame_messages.typemap
[add] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/frame_messages_forward.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/navigation_params.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/common/typemaps.gni
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/public/test/test_renderer_host.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/renderer/render_frame_impl.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/renderer/render_view_browsertest.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/renderer/render_view_impl.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/BUILD.gn
[add] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/did_commit_provisional_load_interceptor.cc
[add] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/did_commit_provisional_load_interceptor.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/test_render_frame.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/test_render_frame.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/content/test/test_render_frame_host.cc
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/extensions/common/extension_messages.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/mojo/public/cpp/bindings/associated_binding.h
[modify] https://crrev.com/a40712f84aed485b3da6d212938e330ae3b85605/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9

commit ba034e7fe3a33f0ca653903ff4608ab17a57b2f9
Author: Balazs Engedy <engedy@chromium.org>
Date: Fri Oct 27 22:26:28 2017

Provide InterfaceProvider to RFs at creation time.

Every RenderFrameHost exposes an InterfaceProvider to its corresponding
RenderFrame, which is used by content/renderer/, Blink and WebUI JS code
to access frame-scoped services implemented by the RFH. Previously, the
InterfaceProvider was retrieved asynchronously by the RenderFrame through
the FrameHostInterfaceBroker interface shortly after RF construction.

This CL removes the FrameHostInterfaceBroker interface entirely, and
instead provides the InterfaceProvider interface to RenderFrames at
construction time, synchronously. This enables follow-up CLs that will
make the InterfaceProvider interface document-scoped and synchronized
with navigation messages.

Depending on how a given RenderFrame is created, the client end of the
InterfaceProvider interface is plumbed down to the renderer process
through one of the following routes:

 1) For main frames created along with RenderViews to service
    cross-origin top-level navigations, displaying interstitials, and
    window.open() calls with suppressed `window.opener` access, the
    client end of the InterfaceProvider interface is sent down to the
    renderer process as part of CreateViewParams, and plumbed through via
    the new RenderView to the new main-frame RenderFrame.

 2) For main frames created synchronously via window.open() with allowed
    `window.opener` access, the client end of the InterfaceProvider
    interface is sent down to the renderer process as part of the sync
    CreateNewWindowReply and is plumbed through by the opener RenderView
    to the new RenderView, and to the new main-frame RenderFrame.

 3) For child frames, the parent frame takes care of sending down the
    client end of the InterfaceProvider interface as a naked handle in
    the response to the sync FrameHostMsg_CreateChildFrame legacy IPC,
    and supplying to the new child RenderFrame.

 4) For out-of-process child frames, the new RenderFrameHost itself
    takes care of sending down the client end of InterfaceProvider
    interface to the RenderFrame as part of CreateFrameParams.

As far as IPCs are concerned, this is essentially how the |routing_id|
for new frames is passed down to the renderer process.

Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I1b3d113266763a1351018f19b7d7e584fd058a76
Reviewed-on: https://chromium-review.googlesource.com/685235
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512325}
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/frame_tree.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/frame_tree.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/frame_tree_node_blame_context_unittest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/frame_tree_unittest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/navigation_controller_impl_unittest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/render_frame_host_manager_unittest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/render_frame_message_filter.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/frame_host/render_frame_message_filter.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/renderer_host/render_process_host_unittest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/common/frame.mojom
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/common/frame_messages.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/common/renderer.mojom
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/public/test/mock_render_thread.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/public/test/mock_render_thread.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/public/test/render_view_test.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_frame_impl.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_frame_impl_browsertest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_thread_impl.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_view_browsertest.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_view_impl.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/renderer/render_view_impl.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/shell/test_runner/web_frame_test_proxy.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/layouttest_support.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/test_render_frame.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/test_render_frame.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/test_render_frame_host.cc
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/test_render_frame_host.h
[modify] https://crrev.com/ba034e7fe3a33f0ca653903ff4608ab17a57b2f9/content/test/test_render_view_host.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f

commit c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f
Author: Balazs Engedy <engedy@chromium.org>
Date: Thu Nov 02 09:03:01 2017

Avoid using `isolated` wrt. AssociatedInterfaces.

The term `isolated` is already widely used for origins. Using it also
to describe AssociatedInterfacePtrs and AssociatedInterfaceRequests
that are associated with dedicated or a disconnected message pipe 
(mostly for testing) is confusing. Instead, use the words `dedicated`
and `disconnected`, respectively.

Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ie44893453fc0033f09eecac41af725f5123d07e4
Reviewed-on: https://chromium-review.googlesource.com/743011
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513431}
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/ash/shelf/shelf_controller_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/ash/test_media_client.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/ash/wallpaper/wallpaper_controller_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/chrome/browser/ui/search/search_ipc_router.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/bluetooth/frame_connected_bluetooth_devices_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/indexed_db/indexed_db_dispatcher_host_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/service_worker/embedded_worker_test_helper.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/service_worker/service_worker_dispatcher_host_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/service_worker/service_worker_test_utils.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/storage_partition_impl_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/browser/web_contents_binding_set_browsertest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/common/associated_interface_provider_impl.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/public/test/mock_render_process_host.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/renderer/indexed_db/webidbcursor_impl_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/renderer/screen_orientation/screen_orientation_dispatcher_browsertest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/content/renderer/service_worker/service_worker_provider_context_unittest.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/ipc/ipc_channel_mojo.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/ipc/ipc_sync_message_filter.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/mojo/public/cpp/bindings/associated_interface_ptr.h
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/mojo/public/cpp/bindings/lib/associated_interface_ptr.cc
[modify] https://crrev.com/c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f/mojo/public/cpp/bindings/tests/associated_interface_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3b1f3943fb6cbf1fec9bfc95c8c617df24985906

commit 3b1f3943fb6cbf1fec9bfc95c8c617df24985906
Author: Alexander Timin <altimin@chromium.org>
Date: Thu Nov 02 10:02:49 2017

Revert "Avoid using `isolated` wrt. AssociatedInterfaces."

This reverts commit c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f.

Reason for revert: failed compile on waterfall: https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Builder%20%28dbg%29/builds/93746

Original change's description:
> Avoid using `isolated` wrt. AssociatedInterfaces.
> 
> The term `isolated` is already widely used for origins. Using it also
> to describe AssociatedInterfacePtrs and AssociatedInterfaceRequests
> that are associated with dedicated or a disconnected message pipe 
> (mostly for testing) is confusing. Instead, use the words `dedicated`
> and `disconnected`, respectively.
> 
> Bug: 729021
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
> Change-Id: Ie44893453fc0033f09eecac41af725f5123d07e4
> Reviewed-on: https://chromium-review.googlesource.com/743011
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
> Reviewed-by: Ken Rockot <rockot@chromium.org>
> Commit-Queue: Balazs Engedy <engedy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#513431}

TBR=dcheng@chromium.org,jam@chromium.org,rockot@chromium.org,engedy@chromium.org,yzshen@chromium.org

Change-Id: Ia2021071c1fac48ed6ed949506b73ddb859faa17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Reviewed-on: https://chromium-review.googlesource.com/750143
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513437}
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/ash/shelf/shelf_controller_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/ash/test_media_client.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/ash/wallpaper/wallpaper_controller_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/chrome/browser/ui/search/search_ipc_router.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/bluetooth/frame_connected_bluetooth_devices_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/indexed_db/indexed_db_dispatcher_host_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/service_worker/embedded_worker_test_helper.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/service_worker/service_worker_dispatcher_host_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/service_worker/service_worker_test_utils.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/storage_partition_impl_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/browser/web_contents_binding_set_browsertest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/common/associated_interface_provider_impl.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/public/test/mock_render_process_host.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/renderer/indexed_db/webidbcursor_impl_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/renderer/screen_orientation/screen_orientation_dispatcher_browsertest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/content/renderer/service_worker/service_worker_provider_context_unittest.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/ipc/ipc_channel_mojo.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/ipc/ipc_sync_message_filter.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/mojo/public/cpp/bindings/associated_interface_ptr.h
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/mojo/public/cpp/bindings/lib/associated_interface_ptr.cc
[modify] https://crrev.com/3b1f3943fb6cbf1fec9bfc95c8c617df24985906/mojo/public/cpp/bindings/tests/associated_interface_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7

commit f0b497ed4f540011e8f8e53ff7e7ad233e9198c7
Author: Balazs Engedy <engedy@chromium.org>
Date: Sat Nov 04 00:50:21 2017

Reland "Avoid using `isolated` wrt. AssociatedInterfaces."

This is a reland of c9fe34f2f9f675e4331d731cc813fa8b0adbdf7f, which updates
a new call site of mojo::MakeIsolatedRequest that was introduced after the
the CL went through the CQ try jobs but before the CL landed.

Original change's description:
> Avoid using `isolated` wrt. AssociatedInterfaces.
> 
> The term `isolated` is already widely used for origins. Using it also
> to describe AssociatedInterfacePtrs and AssociatedInterfaceRequests
> that are associated with dedicated or a disconnected message pipe 
> (mostly for testing) is confusing. Instead, use the words `dedicated`
> and `disconnected`, respectively.
> 
> Bug: 729021
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
> Change-Id: Ie44893453fc0033f09eecac41af725f5123d07e4
> Reviewed-on: https://chromium-review.googlesource.com/743011
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
> Reviewed-by: Ken Rockot <rockot@chromium.org>
> Commit-Queue: Balazs Engedy <engedy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#513431}

TBR=jam@chromium.org, dcheng@chromium.org, yzshen@chromium.org, rockot@chromium.org

Bug: 729021
Change-Id: I544b2f644830038e5993fbe4a657ba3b7a7ae62e
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Reviewed-on: https://chromium-review.googlesource.com/753624
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513995}
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ash/message_center/notifier_settings_view_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ash/shelf/shelf_controller_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ash/test_media_client.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ash/wallpaper/wallpaper_controller_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/chrome/browser/ui/search/search_ipc_router.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/bluetooth/frame_connected_bluetooth_devices_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/dom_storage/local_storage_context_mojo_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/indexed_db/indexed_db_dispatcher_host_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/service_worker/embedded_worker_test_helper.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/service_worker/service_worker_dispatcher_host_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/service_worker/service_worker_test_utils.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/storage_partition_impl_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/browser/web_contents_binding_set_browsertest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/common/associated_interface_provider_impl.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/public/test/mock_render_process_host.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/renderer/indexed_db/webidbcursor_impl_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/renderer/screen_orientation/screen_orientation_dispatcher_browsertest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/content/renderer/service_worker/service_worker_provider_context_unittest.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ipc/ipc_channel_mojo.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/ipc/ipc_sync_message_filter.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/mojo/public/cpp/bindings/associated_interface_ptr.h
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/mojo/public/cpp/bindings/lib/associated_interface_ptr.cc
[modify] https://crrev.com/f0b497ed4f540011e8f8e53ff7e7ad233e9198c7/mojo/public/cpp/bindings/tests/associated_interface_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c

commit 0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c
Author: Balazs Engedy <engedy@chromium.org>
Date: Wed Dec 06 21:30:23 2017

Rebind RF's InterfaceProvider on navigation.

Every RenderFrameHost exposes an InterfaceProvider to its corresponding
RenderFrame, which is used by content/renderer/, Blink and WebUI JS code
to access frame-scoped services implemented by the RenderFrameHost.

Previously, for each frame, there was just a single InterfaceProvider
interface connection that was used throughout the entire lifetime of the
RenderFrame. The client end of this connection was passed in to the
RenderFrame synchronously at construction time, and was then bound to
|RenderFrameImpl::remote_interfaces_|.

As of this CL, this primordial InterfaceProvider interface connection
will only service interface requests originating from the initial empty
document in the frame. For each subsequent cross-document navigation, a
new message pipe is created, with its client end being bound to the
RenderFrame's |remote_interfaces_| when the navigation commits, and its
request end sent to the browser process as part of the
DidCommitProvisionalLoad message.

The one and only exception to this rule is when a browsing context is
navigated from the initial empty document to another same-origin
document, in which case the global object (i.e. the Window instance)
associated with the initial document is reused for the new Document
corresponding to the first real navigation committed. This is to
support the following use-case:
  1) Parent frame dynamically injects an <iframe>.
  2) The parent frame calls `child.contentDocument.write(...)` to inject
     script that may stash objects on the child frame's global object
     (LocalDOMWindow). Internally, these objects may be using Mojo
     services exposed by the RenderFrameHost. The InterfaceRequests for
     these will be en-route to the RenderFrameHost for some time.
  3) The `child` frame commits a first real load that is same-origin.
  4) The global object in the child frame's browsing context is re-used.
  5) When the InterfaceRequests arrive to the browser process, the
     RenderFrameHost should not discard these requests, so that JS
     objects stashed on the global object will continue to work.

On the browser process side, when the RenderFrameHost receives an
InterfaceProvider request along with DidCommitProvisionalLoad, it
immediately breaks the old InterfaceProvider connection. Pending
interface requests on the old connection are dropped, if any. Interface
requests possibly pending on the new InterfaceProvider connection are
only dispatched after WebContentsObserver::DidFinishNavigation fires.

This ensures that interface requests racing with navigation commit will
be either ignored, or correctly serviced in the security context of the
document they originated from. In other words, when an interface request
is dispatched, the invariant will hold that calling GetLastCommittedURL
on the RenderFrameHost will return a URL that matches that of the
document from which the interface request actually originated from.

Note that |remote_interfaces_| remains a non-Channel-associated
interface. Also note that it remains the responsibility of individual
features using |remote_interfaces_| to close interface connections
already established through the InterfaceProvider when a cross-document
navigation commits, if needed in particular use-case.

Bug: 729021
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I1eb4aa78be9627f70fdf6e18af570f083b9e306d
Reviewed-on: https://chromium-review.googlesource.com/735686
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Max Morin <maxmorin@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522198}
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/bad_message.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/interface_provider_filtering.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/interface_provider_filtering.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/renderer_host/render_widget_host_view_browsertest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/security_exploit_browsertest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/browser/web_contents/web_contents_impl_unittest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/common/frame.mojom
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/public/test/mock_render_thread.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/public/test/mock_render_thread.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/public/test/navigation_simulator.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/public/test/navigation_simulator.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/public/test/render_view_test.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/renderer/media/audio_ipc_factory.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/renderer/media/media_factory.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/renderer/render_frame_impl.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/renderer/render_frame_impl_browsertest.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/shell/test_runner/web_frame_test_client.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/shell/test_runner/web_frame_test_client.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/shell/test_runner/web_frame_test_proxy.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/BUILD.gn
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/did_commit_provisional_load_interceptor.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/did_commit_provisional_load_interceptor.h
[add] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/frame_host_test_interface.mojom
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/test_render_frame.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/test_render_frame.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/test_render_frame_host.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/content/test/test_render_frame_host.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/media/mojo/clients/mojo_renderer_factory.cc
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/media/mojo/clients/mojo_renderer_factory.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/services/service_manager/public/cpp/interface_provider.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.cpp
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/frame/LocalFrameClient.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/loader/DocumentLoader.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/loader/EmptyClients.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/public/BUILD.gn
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/public/web/WebFrameClient.h
[add] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/third_party/WebKit/public/web/WebGlobalObjectReusePolicy.h
[modify] https://crrev.com/0c8d550bb4f71ad5fb82abbcf772abb9ff42e25c/tools/metrics/histograms/enums.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68815a3f56acd21576ce2a4bef51cd35c9ee6a02

commit 68815a3f56acd21576ce2a4bef51cd35c9ee6a02
Author: Balazs Engedy <engedy@chromium.org>
Date: Thu Dec 07 15:26:01 2017

Do not assume interface dispatch before DidStopLoading.

EarlyInterfaceRequestsFromNewDocumentDispatchedAfterNavigationFinished
in RenderFrameHostImplBrowserTest previously assumed that an interface
request issued right away by the newly committed document will be
necessarily dispatched before DidStopLoading.

This is incorrect: tiny testing documents with no subresources to load
might stop loading and send FrameHostMsg_DidStopLoading shortly after
the load committed, so RenderFrameHostImpl::OnDidStopLoading might end
up being invoked before RemderFrameHostImpl::GetInterface is.

TBR=nasko@chromium.org

Bug:  792863 , 729021
Change-Id: I6a631e7e996480fcfd148a54faa8a977386d9e03
Reviewed-on: https://chromium-review.googlesource.com/814096
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522431}
[modify] https://crrev.com/68815a3f56acd21576ce2a4bef51cd35c9ee6a02/content/browser/frame_host/render_frame_host_impl_browsertest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25bda34923ca63b231679c07c3bee953d2ab9cca

commit 25bda34923ca63b231679c07c3bee953d2ab9cca
Author: Balazs Engedy <engedy@chromium.org>
Date: Fri Dec 08 09:16:56 2017

Simplify routing IDs in RenderViewTests.

RenderViewTests previously used hard-coded routing IDs for the default
RenderView, as well as generated routing IDs for child frames and for
additional RenderViews created through window.open().

Unfortunately, the `renderer_fuzzer` uses the same RenderViewTest test
fixture instance to load a bunch of HTML test cases, and the magic
routing ID constants were chosen poorly so that after about 50 inputs
the generated subframe routing ID clashed with that of the main frame.

This CL removes all magic constants, and instead utilizes a single,
ever-increasing counter to generate unique routing IDs for widgets,
views, as well as frames.

Bug:  792882 , 729021
Change-Id: I528790bb05a457b54b351a38d67cb3646f68e332
Reviewed-on: https://chromium-review.googlesource.com/814994
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522743}
[modify] https://crrev.com/25bda34923ca63b231679c07c3bee953d2ab9cca/content/public/test/mock_render_thread.cc
[modify] https://crrev.com/25bda34923ca63b231679c07c3bee953d2ab9cca/content/public/test/mock_render_thread.h
[modify] https://crrev.com/25bda34923ca63b231679c07c3bee953d2ab9cca/content/public/test/render_view_test.cc

One simple thing we might consider doing here is using the  NavigationHandle::GetNavigationId(), which is a unique identifier generated in the browser process, as the committed document's id. It might work something like this:

* navigation is initiated, and generates its nav id
* browser process sends this nav id to the render process before commit, perhaps piggybacked on the mojo message that sends the initial bytes of the main resource to the render process
* if the render process commits, it echoes this identifier back to the browser as part of the commit ipc
* browser and render then have a synchronized identifier to identify the currently committed document in the render process

Based on discussion earlier in this bug, we would not send a new nav id for same document navigations.

As explained offline, we're refactoring navigation mojo methods into a per-navigation interface, which should make the assigning of a navigation id much easier. See issue 784904 for details.

We also discussed what to do with the document id in case of document.write. I think the general consensus is that we want a new document id in that case.

The current long-term plan is still to make RenderFrameHostImpl / RenderFrameImpl lifetime match Window lifetime in Blink. This will make it closer to Document lifetime as well except in one exceptional case.

However, given that Document itself does *not* change when document.write() is I'd like to see us clean up frames first; it's quite confusing as it is, and adding a fourth ID that doesn't correlate with frame, window, or document lifetime seems like it would be trouble.

Reporting a bug which I think is introduced from this feature's release in Chrome 65.*
It is causing the entire app to crash ("Aw snap").

Reproducing steps:
1. Go to https://web.flock.com
2. Sign up or login using your gmail account
3. When through, the app crashes entirely after loading some sections of the app.

The center section is an iframe which probably could be the reason of this crash.

If anyone of you would be aware of this issue or a work around, kindly update here.

I could reproduce the crash, and looking into it right now.

As a matter of fact, let's open a new bug for this: Issue 821039.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c8a7cccf6d7bd53821b7e860446d3768ff0aaa91

commit c8a7cccf6d7bd53821b7e860446d3768ff0aaa91
Author: Balazs Engedy <engedy@chromium.org>
Date: Mon Mar 12 23:00:49 2018

Let `about:blank#ref` also be classified as initial empty document.

Before this CL, content::FrameTreeNode used to classify only the literal
`about:blank` as the URL corresponding to the initial empty document.

However, navigations from the initial empty document to URLs such as
`about:blank#ref` are same-document and therefore re-use the initial
empty document, so committing any such same-document navigations should
not be considered "real loads" by FrameTreeNode (given they are not
considered "real loads" by Blink).

This CL changes FrameTreeNode::SetCurrentURL() to use !IsAboutBlank() to
determine whether the first real load is currently taking place in a
frame, that is, whether it is a first time a URL is being committed that
is not the initial empty document (modulo an optional #fragment).

Bug:  821022 , 729021
Change-Id: I040a11f58bf27174e0c450377f8cd81a7abeac70
Reviewed-on: https://chromium-review.googlesource.com/958925
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542645}
[modify] https://crrev.com/c8a7cccf6d7bd53821b7e860446d3768ff0aaa91/content/browser/frame_host/frame_tree_node.cc
[modify] https://crrev.com/c8a7cccf6d7bd53821b7e860446d3768ff0aaa91/content/browser/frame_host/render_frame_host_impl_browsertest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/435b91b4297de17578c3cf4cd0375dbdc394eba1

commit 435b91b4297de17578c3cf4cd0375dbdc394eba1
Author: Balazs Engedy <engedy@chromium.org>
Date: Sun Mar 25 10:34:43 2018

Let `about:blank#ref` also be classified as initial empty document.

Before this CL, content::FrameTreeNode used to classify only the literal
`about:blank` as the URL corresponding to the initial empty document.

However, navigations from the initial empty document to URLs such as
`about:blank#ref` are same-document and therefore re-use the initial
empty document, so committing any such same-document navigations should
not be considered "real loads" by FrameTreeNode (given they are not
considered "real loads" by Blink).

This CL changes FrameTreeNode::SetCurrentURL() to use !IsAboutBlank() to
determine whether the first real load is currently taking place in a
frame, that is, whether it is a first time a URL is being committed that
is not the initial empty document (modulo an optional #fragment).

Bug:  821022 , 729021
Change-Id: I040a11f58bf27174e0c450377f8cd81a7abeac70
Reviewed-on: https://chromium-review.googlesource.com/958925
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#542645}(cherry picked from commit c8a7cccf6d7bd53821b7e860446d3768ff0aaa91)
Reviewed-on: https://chromium-review.googlesource.com/979652
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#418}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/435b91b4297de17578c3cf4cd0375dbdc394eba1/content/browser/frame_host/frame_tree_node.cc
[modify] https://crrev.com/435b91b4297de17578c3cf4cd0375dbdc394eba1/content/browser/frame_host/render_frame_host_impl_browsertest.cc