NOT YET READY: Improve granularity of window namespaces in Blink.

Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

Testing via:
(all tests below pass before and after the CL, except for
ProcessReuseVsBrowsingInstance which is fixed by this CL)

- New tests:
    - ProcessManagementTest::ProcessReuseVsBrowsingInstance
      (web -> web shouldn't violate browsing instance)
    - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
      (extension/about:blank -> extension can violate browsing instance)

- Existing tests:
    - ExtensionApiTest.WindowsCreateVsSiteInstance
      (chrome.windows.create violates browsing instance in a weird way)
    - AppBackgroundPageApiTest.Basic
      (hosted app -> background page can violate browsing instance;
       tests handling of mapping of web urls [full url, not just origin]
       to extensions)

- Manual testing:
  - Hangouts *extension* continues to work (sufficient to validate that sign-in works).

BUG=718489
TEST=See above.

[Łukasz Anforowicz, 2017-05-08 22:49:56]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-08 22:57:51]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-09 00:25:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-09 00:25:15]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Łukasz Anforowicz, 2017-05-09 04:12:37]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-09 04:13:22]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-09 04:56:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-09 04:56:03]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Łukasz Anforowicz, 2017-05-11 16:39:11]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-11 16:40:12]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-11 16:54:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-11 16:54:56]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Łukasz Anforowicz, 2017-05-25 23:44:57]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-25 23:46:21]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-25 23:57:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-25 23:57:24]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Łukasz Anforowicz, 2017-05-26 17:29:09]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-26 17:29:33]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 17:32:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-26 17:32:41]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Łukasz Anforowicz, 2017-05-26 17:39:33]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL is:

1. Adding a |browsing_instance_id_| field to blink::Page:
   - The new field is used to implement a new instance method:
     const PageSet& blink::Page::RelatedPages()
   - The new field is populated via a new, mandatory argument of
     Page::CreateOrdinary This argument is plumbed from a new, optional
     argument of WebView::Create (optional so that print preview and
     tests default to being in a browsing instance not related to any
     other pages).

2. Adding a |browsing_instance_id_| field to content::RenderViewImpl:
   - The new field is used to propagate opener's browsing_instance_id_
     when creating a new view in RenderViewImpl's implementation of
     WebViewClient::CreateView.

3. Adding an id to content::BrowsingInstance and exposing it via
   content::SiteInstanceImpl::GetBrowsingInstanceId.

BUG=718489
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.  In particular:
    - We can consider disabling extension <-> web lookup after having
      chrome.windows.create establish a real opener relationship
    - We need to gather UMAs to check what kinds of lookup can be
      restricted.
    - Also see the comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
==========

[Łukasz Anforowicz, 2017-05-26 19:32:53]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-26 19:33:30]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-26 19:36:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-26 19:36:21]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Łukasz Anforowicz, 2017-05-26 21:42:06]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-26 21:42:42]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-05-26 21:44:12]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.  In particular:
    - We can consider disabling extension <-> web lookup after having
      chrome.windows.create establish a real opener relationship
    - We need to gather UMAs to check what kinds of lookup can be
      restricted.
    - Also see the comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.
    - This is sufficient to support chrome.windows.create API that the
      Hangouts extension depends on.
    - Some future restriction ideas in a comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

[Łukasz Anforowicz, 2017-05-26 21:57:03]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.
    - This is sufficient to support chrome.windows.create API that the
      Hangouts extension depends on.
    - Some future restriction ideas in a comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.
    - This is sufficient to support chrome.windows.create API that the
      Hangouts extension depends on.
    - Some future restriction ideas are in a comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

[commit-bot: I haz the power, 2017-05-26 23:04:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-26 23:04:41]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Łukasz Anforowicz, 2017-05-26 23:59:01]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-26 23:59:17]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-27 00:09:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-27 00:09:15]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[Łukasz Anforowicz, 2017-05-27 02:18:15]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-27 02:18:31]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-27 03:34:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-27 03:34:24]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Łukasz Anforowicz, 2017-05-30 20:52:02]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-30 20:52:37]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-30 20:55:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-30 20:55:27]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Łukasz Anforowicz, 2017-05-31 21:32:16]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- A new browser test for verifying browsing instance boundaries when the
  renderer process limit is hit:
  ProcessManagementTest.ProcessReuseVsBrowsingInstance.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback implements the old, process-wide lookup,
    but in the future we should restrict it further.
    - This is sufficient to support chrome.windows.create API that the
      Hangouts extension depends on.
    - Some future restriction ideas are in a comment in
      extensions::ExtensionFrameHelper::FindFrame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all local frames in the
    given process, but requires that the |relative_to_frame| is an
    extension frame.
    - In the future we should restrict it further:
      - We surely want to disallow looking up frames from another origin
        (e.g. from another extension in case of renderer process reuse).
      - We should investigate if the lookup can be restricted in other
        ways.  Maybe we can allow the lookup only if the target frame is
        a background content/page.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

[Łukasz Anforowicz, 2017-05-31 22:00:51]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 22:01:52]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-05-31 22:18:55]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all local frames in the
    given process, but requires that the |relative_to_frame| is an
    extension frame.
    - In the future we should restrict it further:
      - We surely want to disallow looking up frames from another origin
        (e.g. from another extension in case of renderer process reuse).
      - We should investigate if the lookup can be restricted in other
        ways.  Maybe we can allow the lookup only if the target frame is
        a background content/page.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all local frames in the
    given process, but requires that the |relative_to_frame| is an
    extension frame.
    - In the future we should restrict it further:
      - We surely want to disallow looking up frames from another origin
        (e.g. from another extension in case of renderer process reuse).
      - We should investigate if the lookup can be restricted in other
        ways.  Maybe we can allow the lookup only if the target frame is
        a background content/page.  Before --isolate-extensions
        extension frames in unblessed processes were probably unable to
        lookup unrelated frames from the same extension

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

[Łukasz Anforowicz, 2017-05-31 23:10:49]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 23:11:25]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-05-31 23:28:33]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-31 23:29:32]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-01 02:22:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-01 02:22:14]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Łukasz Anforowicz, 2017-06-01 03:35:44]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-01 03:35:56]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-06-01 03:50:23]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all local frames in the
    given process, but requires that the |relative_to_frame| is an
    extension frame.
    - In the future we should restrict it further:
      - We surely want to disallow looking up frames from another origin
        (e.g. from another extension in case of renderer process reuse).
      - We should investigate if the lookup can be restricted in other
        ways.  Maybe we can allow the lookup only if the target frame is
        a background content/page.  Before --isolate-extensions
        extension frames in unblessed processes were probably unable to
        lookup unrelated frames from the same extension

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

[commit-bot: I haz the power, 2017-06-01 05:16:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-01 05:16:33]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-01 16:23:09]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

BUG=718489
TEST=On top of tryjobs, I've also verified the Hangouts *extension* still works.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

Testing via:
(all tests below pass before and after the CL, except for
ProcessReuseVsBrowsingInstance which is fixed by this CL)

- New tests:
    - ProcessManagementTest::ProcessReuseVsBrowsingInstance
      (web -> web shouldn't violate browsing instance)
    - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
      (extension/about:blank -> extension can violate browsing instance)

- Existing tests:
    - ExtensionApiTest.WindowsCreateVsSiteInstance
      (chrome.windows.create violates browsing instance in a weird way)
    - AppBackgroundPageApiTest.Basic
      (hosted app -> background page can violate browsing instance;
       tests handling of mapping of web urls [full url, not just origin]
       to extensions)

- Manual testing:
  - Hangouts *extension* continues to work (sufficient to validate that sign-in
works).

BUG=718489
TEST=See above.
==========

[Łukasz Anforowicz, 2017-06-01 22:35:24]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-01 22:36:35]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-06-01 22:59:52]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-01 23:00:37]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-02 01:00:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-02 01:00:17]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Łukasz Anforowicz, 2017-06-05 22:14:00]

lukasza@chromium.org changed reviewers:
+ dcheng@chromium.org

[Łukasz Anforowicz, 2017-06-05 22:14:02]

dcheng@, could you PTAL?  I think it is okay to start reviewing this CL, given
that the CL it depends on (https://crrev.com/2921753002 for
https://crbug.com/713888) seems to be supported by others.

[Łukasz Anforowicz, 2017-06-08 17:14:07]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-08 17:14:34]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-08 19:00:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-08 19:00:58]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-09 16:21:51]

Description was changed from

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

Testing via:
(all tests below pass before and after the CL, except for
ProcessReuseVsBrowsingInstance which is fixed by this CL)

- New tests:
    - ProcessManagementTest::ProcessReuseVsBrowsingInstance
      (web -> web shouldn't violate browsing instance)
    - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
      (extension/about:blank -> extension can violate browsing instance)

- Existing tests:
    - ExtensionApiTest.WindowsCreateVsSiteInstance
      (chrome.windows.create violates browsing instance in a weird way)
    - AppBackgroundPageApiTest.Basic
      (hosted app -> background page can violate browsing instance;
       tests handling of mapping of web urls [full url, not just origin]
       to extensions)

- Manual testing:
  - Hangouts *extension* continues to work (sufficient to validate that sign-in
works).

BUG=718489
TEST=See above.
==========

to

==========
Improve granularity of window namespaces in Blink.

This CL ensures that blink::FrameTree::Find(const AtomicString& name)
only looks for a match in the current set of related browsing contexts
(represented in the browser by content::BrowsingInstance).  This CL
means that window.open's behavior won't change just because a renderer
process happens to host multiple unrelated browsing contexts (possible
for example after hitting the process limit).

This CL consists of 3 parts:

- New browser tests.
  - ProcessManagementTest.ProcessReuseVsBrowsingInstance
    for verifying browsing instance boundaries when the
    renderer processes get reused.
  - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
    for verifying that extensions can still lookup unrelated frames
    from the same extension.

- Having blink::Page maintain a set of related pages.
  - Page::next_related_page_ and Page::prev_related_page_ form a
    circular, double-linked list of related pages.
  - Page::CreateOrdinary takes a new |opener| parameter and treats the
    new page and the |opener| as related and puts them on the same list.
  - |opener| is propagated from content::RenderViewImpl, through
    blink::WebViewImpl into blink::Page.

- Falling back to blink embedder when blink::FrameTree::Find finds no frame
  with the given name.
  - The fallback is needed to preserve the old behavior for extensions.
  - The fallback goes through blink::LocalFrameClient,
    blink::WebFrameClient / content::RenderFrameImpl,
    content::ContentRendererClient / ::ChromeContentRendererClient,
    ::ChromeExtensionsRendererClient and finally is implemented
    by extensions::ExtensionFrameHelper.
  - Currently the fallback iterates through all same-origin frames in
    the given process, but requires that the |relative_to_frame| is an
    extension frame.

Testing via:
(all tests below pass before and after the CL, except for
ProcessReuseVsBrowsingInstance which is fixed by this CL)

- New tests:
    - ProcessManagementTest::ProcessReuseVsBrowsingInstance
      (web -> web shouldn't violate browsing instance)
    - ExtensionFunctionalTest.FindingUnrelatedExtensionFramesFromAboutBlank
      (extension/about:blank -> extension can violate browsing instance)

- Existing tests:
    - ExtensionApiTest.WindowsCreateVsSiteInstance
      (chrome.windows.create violates browsing instance in a weird way)
    - AppBackgroundPageApiTest.Basic
      (hosted app -> background page can violate browsing instance;
       tests handling of mapping of web urls [full url, not just origin]
       to extensions)

- Manual testing:
  - Hangouts *extension* continues to work (sufficient to validate that sign-in
works).

BUG=718489
TEST=See above.
==========