Renderer client id is propagated via command line flags, so in single
process mode RenderThreadImpl gets initialized with the default client
id of 1, whereas the browser allocates a globally unique client id for
each renderer.
Viz frame sinks are embedded in a hierarchy which identifies embedders
by their client ids. So requests made by the renderer to embed other
surfaces are rejected by EmbeddedFrameSinkProviderImpl because the
client ids don't match.
This CL fixes that by propagating the client id from the browser to
RenderThreadImpl in single process mode, and includes related minor code
cleanup.
Bug: 1015988
Change-Id: I758f19df05ad6dc083e01e8cfc760f76ca1831a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1869376
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#708319}
Only invalidate for high contrast and dark mode if the system colors
changed, if the preferred color scheme changed, if the state of high
contrast changed, or if the state of dark mode changed.
Bug: 970285
Change-Id: I6da9787b84ba3790a94df5b961c6e1ec2a762270
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1869758
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Kevin Babbitt <kbabbitt@microsoft.com>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#707897}
This is a preliminary step to Onion souping content::PeerConnectionTracker.
The CL migrates both content::PeerConnectionTracker (renderer) and
content::PeerConnectionTrackerHost (browser) classes away from old
IPC mechanism, to use Mojo.
Additionally, the CL removes from:
- PeerConnectionTracker
* the inheritance from content::RenderThreadObserver, as well as the respective
overridden methods, namely OnControlMessageReceived().
- PeerConnectionTrackerHost
* the inheritance from content::BrowserMessageFilter and
content::BrowserAssociatedInterface, as well as the respective overridden,
namely OnMessageReceived(), OverrideThreadForMessage(), OnChannelConnected(),
OnChannelClosing().
It is important to note that PeerConnectionTrackerHost now operates solely
on the UI thread, so the CL removes some threading jumps between UI and IO
threads.
Last, content/common/media/peer_connection_tracker_messages.h (which declares
the macro-based IPC messages) is now gone.
BUG=787254
TBR=jam@chromium.org
Change-Id: I3ce5af1853384146d893da2a34c333aad80f5255
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1831197
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#707672}
This reverts commit f4bc92d6c5.
Reason for revert: did not resolve flakes.
Original change's description:
> Revert "Resubmit: Lower priority of processes hosting exclusively ads."
>
> This reverts commit 4ba7eb3aa4.
>
> Reason for revert: spec revert for
> crbug.com/1014952
> crbug.com/1015014
> crbug.com/1015013
> crbug.com/1014951
>
> Original change's description:
> > Resubmit: Lower priority of processes hosting exclusively ads.
> >
> > This change adds a variable to ChildProcessPriorityLauncher to
> > indicate whether the associated process is only used to run tasks for
> > ad frames (low priority frames). That variable is then used by the
> > RenderProcessHost to background the frame in those cases. Notification
> > happens in the RenderProcessHost via new UpdateFrameWithPriority.
> >
> > Note: Identification of ad frames is done as per the AdTagging project.
> > Frames that have been marked as ads remain ads, and thus the
> > RenderProcessHost will remain low priority if the frame is navigated
> > to any other non-ad URL within the same process (same domain).
> >
> > Currently this is behind a feature which is off by default.
> > We will be experimenting with this to determine its impact on
> > both ads and in the browser as a whole.
> >
> > TBR=dcheng@chromium.org,gab@chromium.org,pbos@chromium.org,jkarlin@chromium.org
> >
> > Bug: 979234
> > Change-Id: I1acd1b8de7e66f8b2c47564df5e708f9b41f72a6
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1855680
> > Commit-Queue: Eric Robinson <ericrobinson@chromium.org>
> > Reviewed-by: Alexander Timin <altimin@chromium.org>
> > Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#706049}
>
> TBR=alexmos@chromium.org,altimin@chromium.org,ericrobinson@chromium.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: 979234,1014951,1014952,1015013,1015014
> Change-Id: Ib719e3f70371b7941d0b27f9bc171594149dd24e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1864618
> Commit-Queue: John Budorick <jbudorick@chromium.org>
> Reviewed-by: John Budorick <jbudorick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#706625}
TBR=alexmos@chromium.org,altimin@chromium.org,jbudorick@chromium.org,ericrobinson@chromium.org
Bug: 979234, 1014951, 1014952, 1015013, 1015014
Change-Id: I6625c321b9f7a384ed3407b862d3c04b45dfb735
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1865562
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706928}
This reverts commit 4ba7eb3aa4.
Reason for revert: spec revert for
crbug.com/1014952
crbug.com/1015014
crbug.com/1015013
crbug.com/1014951
Original change's description:
> Resubmit: Lower priority of processes hosting exclusively ads.
>
> This change adds a variable to ChildProcessPriorityLauncher to
> indicate whether the associated process is only used to run tasks for
> ad frames (low priority frames). That variable is then used by the
> RenderProcessHost to background the frame in those cases. Notification
> happens in the RenderProcessHost via new UpdateFrameWithPriority.
>
> Note: Identification of ad frames is done as per the AdTagging project.
> Frames that have been marked as ads remain ads, and thus the
> RenderProcessHost will remain low priority if the frame is navigated
> to any other non-ad URL within the same process (same domain).
>
> Currently this is behind a feature which is off by default.
> We will be experimenting with this to determine its impact on
> both ads and in the browser as a whole.
>
> TBR=dcheng@chromium.org,gab@chromium.org,pbos@chromium.org,jkarlin@chromium.org
>
> Bug: 979234
> Change-Id: I1acd1b8de7e66f8b2c47564df5e708f9b41f72a6
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1855680
> Commit-Queue: Eric Robinson <ericrobinson@chromium.org>
> Reviewed-by: Alexander Timin <altimin@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#706049}
TBR=alexmos@chromium.org,altimin@chromium.org,ericrobinson@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 979234,1014951,1014952,1015013,1015014
Change-Id: Ib719e3f70371b7941d0b27f9bc171594149dd24e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1864618
Commit-Queue: John Budorick <jbudorick@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706625}
This change adds a variable to ChildProcessPriorityLauncher to
indicate whether the associated process is only used to run tasks for
ad frames (low priority frames). That variable is then used by the
RenderProcessHost to background the frame in those cases. Notification
happens in the RenderProcessHost via new UpdateFrameWithPriority.
Note: Identification of ad frames is done as per the AdTagging project.
Frames that have been marked as ads remain ads, and thus the
RenderProcessHost will remain low priority if the frame is navigated
to any other non-ad URL within the same process (same domain).
Currently this is behind a feature which is off by default.
We will be experimenting with this to determine its impact on
both ads and in the browser as a whole.
TBR=dcheng@chromium.org,gab@chromium.org,pbos@chromium.org,jkarlin@chromium.org
Bug: 979234
Change-Id: I1acd1b8de7e66f8b2c47564df5e708f9b41f72a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1855680
Commit-Queue: Eric Robinson <ericrobinson@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706049}
This reverts commit 62fa86d36f.
Reason for revert: This is a reland of https://crrev.com/c/1813306
now that the test failures on dbg component builds were fixed.
Original change's description:
> Revert PeerConnectionDependencyFactory Onion Soup CLs
>
> This CL reverts several Onion Soup CLs related to PeerConnectionDependencyFactory.
> The first one in the chain is the culprit for causing failures in some bots,
> but in order to revert it, it is necessary to revert several follow-up CLs.
>
>
> Revert "Onion soup PeerConnectionDependencyFactory and its direct dependencies"
>
> This reverts commit 7e1e15c375.
>
> Revert "Move filtering_network_manager.h and network_manager_uma.h out of the Blink API"
>
> This reverts commit 8f18d55dd8.
>
> Revert "Move stun_field_trial.h out of the Blink API"
>
> This reverts commit e8cd34ee34.
>
> Revert "Move {ipc,empty}_network_manager.h and out of Blink API"
>
> This reverts commit 2dc64b396a.
>
> Revert "Move socket_client.h out of the Blink API"
>
> This reverts commit b2223b283a.
>
> Revert "Remove rtc_video_{encoder,decoder}_factory_util.h from Blink API"
>
> This reverts commit a438dfe161.
>
> Revert "Move video_codec_factory.h out of the Blink API"
>
> This reverts commit 2fa285a7c6.
>
> Revert "Change blink::PeerConnectionDependencyFactory ownership"
>
> This reverts commit a1ac2f02cd.
>
> Revert "Replace uses of blink::Platform::GetWebRtcAudioDevice"
>
> This reverts commit c19364a15a.
>
> Revert "Remove left-over //content/renderer/p2p/"
>
> This reverts commit f4bbeac1f9.
>
>
> Bug: 1005604
> TBR: treib@chromium.org
>
> Change-Id: I6d287dc1d141721496d5e058639f268b73b1ab09
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1813306
> Commit-Queue: Guido Urdaneta <guidou@chromium.org>
> Auto-Submit: Guido Urdaneta <guidou@chromium.org>
> Reviewed-by: Guido Urdaneta <guidou@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#698024}
TBR=guidou@chromium.org
Change-Id: I191ee9c271047f5c02971b8f7c4ea3d6d0460dbd
Bug: 1005604
Change-Id: I191ee9c271047f5c02971b8f7c4ea3d6d0460dbd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1814600
Reviewed-by: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Kentaro Hara <haraken@chromium.org>
Auto-Submit: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#703731}
This is a reland of 8f0dc9682b
Original change's description:
> Don't PostTask the RenderWidget::Close() call.
>
> The post task in RenderWidget was in order to keep IPC receipt of
> destruction of a frame-based RenderWidget (ie a RenderView in the past)
> from happening while the RenderWidget was already closing due to the
> renderer-side detaching, but running a nested message loop.
>
> The RenderView destruction now already does a PostTask hop in
> RenderThreadImpl before starting destruction of the RenderViewImpl
> and its frame tree and RenderWidgets. A RenderWidget for a frame closes
> when the frame detaches, and that is built to be consistent even if
> it occurs inside of unload. The RenderWidget does not need to be kept
> around after the blink frame and RenderFrame and WebWidget associated
> with it are all gone.
>
> Popups and pepper RenderWidgets can close during a frame unload without
> a consistency problem.
>
> R=dcheng@chromium.org
>
> Bug: 419087
> Change-Id: Ia5f7ca07395f8a5bd2c60a974a0fb4fb5092d872
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1832612
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: danakj <danakj@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#702868}
TBR=dcheng
Bug: 419087
Change-Id: I0f68df454e2873d7e6f3eeb38ff41563c16f6a76
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1841942
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702977}
This reverts commit 8f0dc9682b.
Reason for revert: Suspected of causing webkit_layout_tests to fail in http/tests/misc/frame-detached-in-animationstart-event.html on WebKit Linux ASAN.
Original change's description:
> Don't PostTask the RenderWidget::Close() call.
>
> The post task in RenderWidget was in order to keep IPC receipt of
> destruction of a frame-based RenderWidget (ie a RenderView in the past)
> from happening while the RenderWidget was already closing due to the
> renderer-side detaching, but running a nested message loop.
>
> The RenderView destruction now already does a PostTask hop in
> RenderThreadImpl before starting destruction of the RenderViewImpl
> and its frame tree and RenderWidgets. A RenderWidget for a frame closes
> when the frame detaches, and that is built to be consistent even if
> it occurs inside of unload. The RenderWidget does not need to be kept
> around after the blink frame and RenderFrame and WebWidget associated
> with it are all gone.
>
> Popups and pepper RenderWidgets can close during a frame unload without
> a consistency problem.
>
> R=dcheng@chromium.org
>
> Bug: 419087
> Change-Id: Ia5f7ca07395f8a5bd2c60a974a0fb4fb5092d872
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1832612
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: danakj <danakj@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#702868}
TBR=avi@chromium.org,danakj@chromium.org,dcheng@chromium.org
Change-Id: I6edf67e9d004c7f2fb4f3edd36b2a86f4cb5f27a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 419087
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1841941
Reviewed-by: Samuel Huang <huangs@chromium.org>
Commit-Queue: Samuel Huang <huangs@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702926}
The post task in RenderWidget was in order to keep IPC receipt of
destruction of a frame-based RenderWidget (ie a RenderView in the past)
from happening while the RenderWidget was already closing due to the
renderer-side detaching, but running a nested message loop.
The RenderView destruction now already does a PostTask hop in
RenderThreadImpl before starting destruction of the RenderViewImpl
and its frame tree and RenderWidgets. A RenderWidget for a frame closes
when the frame detaches, and that is built to be consistent even if
it occurs inside of unload. The RenderWidget does not need to be kept
around after the blink frame and RenderFrame and WebWidget associated
with it are all gone.
Popups and pepper RenderWidgets can close during a frame unload without
a consistency problem.
R=dcheng@chromium.org
Bug: 419087
Change-Id: Ia5f7ca07395f8a5bd2c60a974a0fb4fb5092d872
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1832612
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702868}
Convert the remaining bits in both the implementation and clients from the
browser and renderer processes for the viz::mojom::CompositorFrameSink and
viz::mojom::CompositorFrameSinkClient interfaces, and adapt unit tests.
Bug: 955171, 978694
Change-Id: Ic01dd94b8e070794df82668d01e0c45b058737f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1835507
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Mario Sanchez Prada <mario@igalia.com>
Cr-Commit-Position: refs/heads/master@{#702863}
There are several includes of that header because code in chrome/browser and
content/ uses blink::WebCache::ResourceTypeStat(s).
In order to remove the dependency, the definitions of those structs were moved
out of the blink::WebCache class and placed on a new header file in
blink/public/common.
Bug: 1008303
Change-Id: Ic46f991c7a269eb227954c6b1fecdc639d8c8903
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1829381
Commit-Queue: Sergio Villar <svillar@igalia.com>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#701521}
This change adds a variable to ChildProcessPriorityLauncher to
indicate whether the associated process is only used to run tasks for
ad frames (low priority frames). That variable is then used by the
RenderProcessHost to background the frame in those cases. Notification
happens in the RenderProcessHost via new UpdateFrameWithPriority.
Note: Identification of ad frames is done as per the AdTagging project.
Frames that have been marked as ads remain ads, and thus the
RenderProcessHost will remain low priority if the frame is navigated
to any other non-ad URL within the same process (same domain).
Currently this is behind a feature which is off by default.
We will be experimenting with this to determine its impact on
both ads and in the browser as a whole.
Bug: 979234
Change-Id: I33d33bc9c1af16b04db211fda25217bd0b2fa85f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1645978
Commit-Queue: Eric Robinson <ericrobinson@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#700786}
This removes almost all remaining usage of Connector from child
processes, instead preferring use of ChildProcessHost.BindHostReceiver
to acquire process-scoped interfaces from the browser.
The one remaining use case after this CL is for the Device Service's
PowerMonitor API. This is left as a separate change because it requires
substantial additional support code for testing.
Bug: 977637
Change-Id: I679c6d7f5ec01d1bc1bb6852e0f79a3f1650df34
Tbr: penghuang@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1815731
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#700317}
This change exposes LayoutTheme::PlatformColorsDidChange() through
WebRenderTheme. This allows system colors to update dynamically when
new colors are sent from the browser process.
Bug: 970285
Change-Id: Ic3b75dfec668dc5523b0e12765574e66dd35ff8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1797057
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#700308}
This CL converts SingleSampleMetricsProvider{Ptr,Request}
and SingleSampleMetric{Ptr, Request} to new Mojo types.
It also updates AcquireSingleSampleMetric from
single_sample_metrics.mojom and members and methods
which implement it.
Bug: 955171
Change-Id: Ied581a2d392d8c3b4a68b8eacc046e013eac25d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1810176
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Brian White <bcwhite@chromium.org>
Commit-Queue: Julie Kim <jkim@igalia.com>
Cr-Commit-Position: refs/heads/master@{#698758}
This reverts commit 62fa86d36f.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Revert PeerConnectionDependencyFactory Onion Soup CLs
>
> This CL reverts several Onion Soup CLs related to PeerConnectionDependencyFactory.
> The first one in the chain is the culprit for causing failures in some bots,
> but in order to revert it, it is necessary to revert several follow-up CLs.
>
>
> Revert "Onion soup PeerConnectionDependencyFactory and its direct dependencies"
>
> This reverts commit 7e1e15c375.
>
> Revert "Move filtering_network_manager.h and network_manager_uma.h out of the Blink API"
>
> This reverts commit 8f18d55dd8.
>
> Revert "Move stun_field_trial.h out of the Blink API"
>
> This reverts commit e8cd34ee34.
>
> Revert "Move {ipc,empty}_network_manager.h and out of Blink API"
>
> This reverts commit 2dc64b396a.
>
> Revert "Move socket_client.h out of the Blink API"
>
> This reverts commit b2223b283a.
>
> Revert "Remove rtc_video_{encoder,decoder}_factory_util.h from Blink API"
>
> This reverts commit a438dfe161.
>
> Revert "Move video_codec_factory.h out of the Blink API"
>
> This reverts commit 2fa285a7c6.
>
> Revert "Change blink::PeerConnectionDependencyFactory ownership"
>
> This reverts commit a1ac2f02cd.
>
> Revert "Replace uses of blink::Platform::GetWebRtcAudioDevice"
>
> This reverts commit c19364a15a.
>
> Revert "Remove left-over //content/renderer/p2p/"
>
> This reverts commit f4bbeac1f9.
>
>
> Bug: 1005604
> TBR: treib@chromium.org
>
> Change-Id: I6d287dc1d141721496d5e058639f268b73b1ab09
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1813306
> Commit-Queue: Guido Urdaneta <guidou@chromium.org>
> Auto-Submit: Guido Urdaneta <guidou@chromium.org>
> Reviewed-by: Guido Urdaneta <guidou@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#698024}
TBR=guidou@chromium.org,jochen@chromium.org
Change-Id: I61215b50fb35dc3be9e3882f7fab36a7efcb53ec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1005604
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1814598
Reviewed-by: Antonio Gomes <tonikitoo@igalia.com>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#698089}
This CL reverts several Onion Soup CLs related to PeerConnectionDependencyFactory.
The first one in the chain is the culprit for causing failures in some bots,
but in order to revert it, it is necessary to revert several follow-up CLs.
Revert "Onion soup PeerConnectionDependencyFactory and its direct dependencies"
This reverts commit 7e1e15c375.
Revert "Move filtering_network_manager.h and network_manager_uma.h out of the Blink API"
This reverts commit 8f18d55dd8.
Revert "Move stun_field_trial.h out of the Blink API"
This reverts commit e8cd34ee34.
Revert "Move {ipc,empty}_network_manager.h and out of Blink API"
This reverts commit 2dc64b396a.
Revert "Move socket_client.h out of the Blink API"
This reverts commit b2223b283a.
Revert "Remove rtc_video_{encoder,decoder}_factory_util.h from Blink API"
This reverts commit a438dfe161.
Revert "Move video_codec_factory.h out of the Blink API"
This reverts commit 2fa285a7c6.
Revert "Change blink::PeerConnectionDependencyFactory ownership"
This reverts commit a1ac2f02cd.
Revert "Replace uses of blink::Platform::GetWebRtcAudioDevice"
This reverts commit c19364a15a.
Revert "Remove left-over //content/renderer/p2p/"
This reverts commit f4bbeac1f9.
Bug: 1005604
TBR: treib@chromium.org
Change-Id: I6d287dc1d141721496d5e058639f268b73b1ab09
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1813306
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Auto-Submit: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698024}
... off of content::RenderThreadImpl.
This CL changes the ownership of blink::PeerConnectionDependencyFactory
as per section 5.1.1 in the design document [1].
[1] https://docs.google.com/document/d/1AJKVA5U4nDkyDB9p4ROrggWXadCxyy-grKaE9KS5vOU/
Quoting the document:
"
PeerConnectionDependencyFactory is currently owned by RenderThreadImpl in content,
which makes it a single object per renderer process. This ownership must be moved to
a suitable place in Blink. A possibility is to keep it as a global object (using
DEFINE_STATIC_LOCAL).
The disadvantage of this approach is that PCDF would never be destroyed, whereas
it is currently destroyed by the RenderThreadImpl destructor, but this is acceptable.
"
This move will allow a set of blink::Platform methods to be removed
(follow up CL).
BUG=787254
R=guidou@chromium.org, haraken@chromium.org
Change-Id: Ie79f13cfd90c56fcbed50142802b0fcda480c43e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1807657
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#697750}
This CL is the main CL that moves peer_connection_dependency_factory.cc|h
from content/renderer/media/webrtc to Blink.
Given that is has many dependencies on content/renderer/p2p and other
content classes, this work had various predecessor CLs, including:
- 1804541, 1795667, 1795669, 1795671, 1798266, 1798274, 1799102,
1799085, 1801068, 1803260, 1803454.
Additionally, some other content/ files that PeerConnectionDependencyFactory
relies on could be moved independently to Blink easily, so this CL moves
them altogether. It includes the following files:
- host_address_request.cc|h
- ipc_socket_factory.cc|h
- mdns_responder_adapter.cc|h
- port_allocator.cc|h
- socket_client_impl.cc|h
- socket_dispatcher.cc|h
... all from content/renderer/p2p, that got moved to third_party/blink/renderer/platform/p2p.
Last, the following Blink (temporary header) got moved out of the API
layer, so its method signature could get updated properly:
- third_party/blink/public/platform/modules/p2p/socket_client_delegate.h (moved to)
third_party/blink/renderer/platform/p2p/socket_client_delegate.h
For the sake of simplicity, this CL:
- keeps the ownership of PeerConnectionDependencyFactory in content's
RenderThreadImpl. In a follow up CL, the ownership will moved to a
suitable place in Blink. A possibility is to keep it as a global
object (DEFINE_STATIC_LOCAL).
BUG=787254, 919392
R=guidou@chromium.org, haraken@chromium.org
Change-Id: I0dada58c447f0c8559ca4b590121f3313a1eebc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1805159
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#697582}
This CL converts RenderFrameMetadataObserverClientRequest,
RenderFrameMetadataObserverClientPtr, and
RenderFrameMetadataObserverClientPtrInfo to new
Mojo types.
It also updates RegisterRenderFrameMetadataObserver
from frame_sink_provider.mojom and methods and members
which implements it with new Mojo types.
Bug: 955171
Change-Id: I1f1fefe865bff8e29b47f437b699e6ac55612881
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1795524
Commit-Queue: Julie Kim <jkim@igalia.com>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#695504}
This CL converts RenderFrameMetadataObserver to new
Mojo types.
It also updates RegisterRenderFrameMetadataObserver
from frame_sink_provider.mojom and methods and members
which implements it with new Mojo types.
Bug: 955171
Change-Id: I8f81269e18dd891a11142f55ddf1355ea4cec7d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1794942
Commit-Queue: Julie Kim <jkim@igalia.com>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#695484}
This CL converts Renderer from //content/common/renderer.mojom
to new Mojo types.
It uses mojo::AssociatedRemote, mojo::PendingAssociatedReceiver,
and AssociatedReceiver instead of RendererAssociatedPtr,
<mojo::AssociatedInterfacePtr<mojom::Renderer>>,
RendererAssociatedRequest and AssociatedBinding.
Bug: 955171
Change-Id: I62e07c83ee79c2adfc7485b18127cdbf5fa18948
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1794543
Commit-Queue: Julie Kim <jkim@igalia.com>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#695473}
The original CL (crrev.com/c/1730889) was reverted because it
seemed to break some extension browser_tests on MSAN bot.
The issue was addressed by crrev.com/c/1775892.
The difference between the original CL and this CL are:
* Using thread pool instead of the IO thread. This change comes from
crrev.com/c/1768490
* Using mojo type adapter. This change is required due to
crrev.com/c/1757604
Original description:
This is practically a revert of https://crrev.com/c/1053042.
The previous change was made to ensure user agent is set for
RenderThreadImpl before creating service workers. However,
service worker code path doesn't rely on RenderThreadImpl's
user agent. User agent is passed as a part of
EmbeddedWorkerStartParams. We don't need to use mojo::Renderer
interface to create EmbeddedWorkerInstanceClient.
This change allows us to choose the thread to create
EmbeddedWorkerInstanceClient, which is a requirement for
off-the-main-thread service worker startup.
Bug: 692909
Change-Id: I96c348ff186254a29a58d0d16faa938f1b0aa272
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1758031
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694027}
This CL converts DocumentInterfaceBroker{Ptr, Request} in content,
blink, extension and media to the new Mojo types and uses
pending_remote<blink.mojom.DocumentInterfaceBroker> in
document_scoped_interface_bundle.mojom and
pending_receiver<blink.mojom.DocumentInterfaceBroker> in
frame_messages.mojom.
Bug: 955171, 978694
Change-Id: Ic0ccabb445febbf8b2bd81aa754fc0abecfb77b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1781900
Commit-Queue: Miyoung Shin <myid.shin@igalia.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693066}
Starting service workers on the IO thread turns out causing mysterious
race conditions (see the comment #3 of linked bug). It's hard to avoid
such race conditions. This CL uses a background thread to start service
workers.
Some methods in blink::scheduler::WorkerThread and blink::WorkerThread
use base::WaitableEvent and will be execution on a background thread
so we need to allow them to use base::ScopedAllowBaseSyncPrimitives.
This CL fixes wpt/shape-detection/idlharness.https.any.html when
OffMainThreadServiceWorkerStartup is enabled.
Bug: 996567
Change-Id: Id987e19e8874d471a961993eca842961c0b0d119
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1768490
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#691419}
Renderer processes currently get all of their process-scoped interfaces
through a Connector. This moves them over to the ChildProcessHost API
which routes directly from the ChildThreadImpl to an IO-thread binding
associated with RenderProcessHostImpl.
The IO-thread BinderRegistry for RPHI is moved from ConnectionFilterImpl
to the IOThreadHostImpl to support this.
The few Blink callsites which use GetConnector()+GetBrowserServiceName()
have been updated to use a new
Platform::GetBrowserInterfaceBrokerProxy() API which returns a
pointer to the new ThreadSafeBrowserInterfaceBrokerProxy type.
This type looks and feels similar to BrowserInterfaceBrokerProxy,
but can be used from any thread. Thread-safety is a useful feature
for process-scoped interface binding, but incurs slight overhead
that is not necessary for context-scoped binding requests; hence the
new type.
As of this CL, use of Platform::GetInterfaceProvider() is
equivalent to Platform::GetThreadSafeBrowserInterfaceBrokerProxy()
in terms of where the requests get routed on the browser side, so
the former can be incrementally converted to the latter.
All dependencies on Connector and deprecated Service Manager service
names have been removed from Blink. Follow-up CLs will remove the
few remaining Connector dependencies from content/renderer and other
child process types, and convert all GetInterfaceProvider() callsites to
use GetBrowserInterfaceBrokerProxy() instead.
Bug: 977637
Change-Id: I60ec171002df812b7ad34b0d87fa972910620fa2
Tbr: yucliu@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1763226
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#689986}
Previously we had both kEnableVizHitTestDrawQuad (VizHitTesting v1) and
kEnableVizHitTestSurfaceLayer(v2). After v1 being shipped, the function
IsVizHitTestingDrawQuadEnabled() was no longer useful. It just returns
!IsVizHitTestingSurfaceLayerEnabled().
Bug: 917015
Change-Id: Id7791763704235238cf0cfbc91bbf580128fa543
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1762588
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#688705}
Post a task to the IO thread to create EmbeddedWorkerInstanceClient
when off-the-main-thread service worker startup is enabled.
This is a tentative workaround to avoid some race conditions which
happen when we make EmbeddedWorkerInstanceClient independent from
RenderThreadImpl (see crbug.com/995134). Ideally we shouldn't need
to post a task. Instead we should bind EmbeddedWorkerInstanceClient
on the IO thread.
Bug: 538751
Change-Id: I4bdb54232fb7abde7d6d1dccf1ac3cb58db16a92
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1761888
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#688436}
