GpuVideoDecodeAccelerator/Host runs IPCs between renderer and GPU
processes, sharing a route with a specific CommandBufferStub/ProxyImpl.
This is a bit tricky to do with Mojo because Media IPCs are a layer
above GPU, and we therefore need CommandBuffer-associated interfaces
that CommandBuffer doesn't know about.
To facilitate this we introduce a generic BindMediaReceiver API on
CommandBuffer which takes a mojo::GenericPendingAssociatedReceiver, i.e.
an associated interface endpoint that can be of any type. We then
introduce a GPU-side hook that the Media stack can use to handle such
requests.
The primordial associated interface introduced here is
GpuAcceleratedVideoDecoderProvider, which in turn has a single IPC for
binding a GpuAcceleratedVideoDecoder/Client pair, also associated with
the CommandBuffer.
This migration removes the last remaining legacy IPC messages used by
the GPU process, so once this is landed we can altogether remove IPC
Channel from GPU code.
Bug: 1196476, 993189
Change-Id: Ife986434b3c10b5796ce995d837a37c29514af49
Test: manually tested with custom extension doing a hardware VP9 decode via pp::VideoDecoder
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2956897
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#893111}
This switches the host away from using the deprecated flag
has_internal_source==true to the standard method for encoding and
sending frames.
This is a minimal patch for switching to the new scheme. Followup CLs
will clean up and remove unused code, once this new scheme has had
some wider testing.
A side-effect of this CL is that the lossless-encode flag is no
longer respected, since the VideoStream no longer manages the encoder.
Bug: 1192865
Change-Id: Ib95038330adeb33ddb0c4b3db77f157c8e925fc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2921257
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893108}
Various storage helper classes have moved from
chrome/browser/browsing_data to components/browsing_data/content and
have simplified type names. Split/update the READMEs to match.
Change-Id: I0045019523b4b0486b7594d0c0aa9831f638e4b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2966678
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893098}
In PEWG, we are considering making the target of a click event the same
as the pointerup target when the pointerup event is dispatched to a
captured target. Currently the click event target is the common
ancestor of pointerdown and pointerup targets. Before we make the
change, we want to check what fraction of page loads would be affected
by this possible change in click target.
Spec discussion: https://github.com/w3c/pointerevents/issues/356
Fixed: 1199099
Change-Id: I9e28c9ab5138f187635352a74befb8cb800aa80a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2876145
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893096}
Currently LCP ignores image that occupy the full viewport of the frame
embedding the image. This CL adds a flag disabled by default which
allows comparing the size to the page viewport instead.
Bug: 1217362
Change-Id: I215a7a7a8ff2550b780e2937509a93d04d42abb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2965459
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893094}
On collections page, display a preview of local images. Clicking on
preview takes user to a new sub-page that displays all local images.
More work on error and loading behavior is necessary to match UX mock.
Render local images in trusted side because they are already data urls.
This reduces code complexity and memory overhead of copying
thumbnail previews across an iframe. Share styles between untrusted
and trusted so that image grids look the same in both cases.
BUG=b/189968254
TEST=browser_tests --gtest_filter="PersonalizationApp*"
Cq-Include-Trybots: luci.chrome.try:linux-chromeos-chrome
Change-Id: I36635c8f0567d0a08ae10566c197d5ba55cc2602
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2957198
Commit-Queue: Jeffrey Young <cowmoo@chromium.org>
Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893091}
When the last incognito tab is closed, the incognito Browser is
recreated. The snackbar coordinator needs to be recreated in this case
to ensure it is associated with the correct Browser instance.
TEST=
1. launch
2. open an incognito tab
3. load page1 in that incognito tab
4. close incognito tab
5. open new incognito tab
6. load page2 in new incognito tab.
Now Bookmark page from overflow/page actions menu or Share page using
the omnibox share icon.
Bug: 1220035, 1220023
Change-Id: I8f11c8a14461c4b2d83e68e967d9c36cf4aa870c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2966760
Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: Mike Dougherty <michaeldo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893090}
Create the Referrer in the receiver instead, using the URL and
ReferrerPolicy as input. Since the receiver is more trustworthy, this
eliminates the following potential issues:
- Sender forgetting to do Referrer sanitization.
- Sender sending different URL and refererer URL.
This also remove a dependency on Blink, and the GN visibility exception
that was needed for the dependency.
Change-Id: I5c7d14a3e23e0ff22af2509c1daa5d10cca6f0b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2964337
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Hui Yingst <nigi@chromium.org>
Reviewed-by: Noel Gordon <noel@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893088}
For use with other embedders aside from Fuchsia, the AV Settings (such
as valid codecs, screen dimensions, etc...) must be exposed and
set-able.
This CL makes the following changes:
- Expose the openscreen::cast::Preferences object as a top-level
parameter for the embedder to provide.
- Expose conversion utilities to be used by embedders in creating the
above object
- Add unit tests to the config conversions file.
Bug: 1207721, internal b/182429089
Change-Id: I3af458b0491d2c413b1feee4801542c88e83bdb9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2935034
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Fabrice de Gans <fdegans@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Ryan Keane <rwkeane@google.com>
Cr-Commit-Position: refs/heads/master@{#893086}
While changing some components/pdf dependencies around, I got this build
failure and others like it, that shows the skia dependency from ui/
(public) headers are not properly propagated to dependencies.
from ../../components/pdf/renderer/pdf_accessibility_tree_unittest.cc:5:
from ../../components/pdf/renderer/pdf_accessibility_tree.h:12:
from ../../content/public/renderer/plugin_ax_tree_source.h:9:
from ../../ui/accessibility/ax_node.h:18:
../../third_party/skia/include/core/SkColor.h:11:10: fatal error:
'include/core/SkImageInfo.h' file not found
Fix the issue using public_deps entries in the relevant GN files.
Change-Id: I487120d0a98c266fbcc392a2f3295a01df262491
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2966257
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893085}
This CL fixes a bug with LanguageItem.isAvailableUiLanguage. The issue
is that we need to do two different types of availability checks:
- Check that a locale exactly matches an available UI language.
- Check that the base language is an available UI language.
This CL splits the current isAvailableUiLanguage method into two and
moves them to AppLocaleUtils.
For an exact match "en" should not be an available language since the
only languages we have strings for are "en-GB" and "en-US". However,
"fr" is an exact match since the languages we have strings for are "fr"
and "fr-CA" (and in this case "fr-FR" would not match).
For the base language match just needs to check if for a given locale
Chrome on Android can be displayed in it. (We rely on Android to
correctly select the strings in "en-GB" when the device locale is
something like "en-AU" or "en-IN").
Bug: 1218113
Change-Id: I2ce6b3342a1200ab4ac9696fd56cfb1adc8bdae4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2953114
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Josh Simmons <jds@google.com>
Commit-Queue: Trevor Perrier <perrier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893083}
Hans is listed in //build/OWNERS for clang config changes, but we have
found that our team regularly updates compiler flags all across
//build/config and //build/toolchain. For better timezone coverage, I
propose we add everyone who has OWNERS over //tools/clang/scripts, which
holds the script that controls the clang package version. As of now,
there are five committers on that list.
R=dpranke@chromium.org
Change-Id: I0f5a0674b6a16fef9eb9afa35eb919efa6a9e21c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2965265
Reviewed-by: Dirk Pranke <dpranke@google.com>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893080}
The content of the templates is not announced to avoid repetition.
However when there is nothing to announce in the template then it is not
focusable anymore. So the swiping doesn't work either. Therefore
templates are announced when they are focused.
Bug: 1217762
Change-Id: Ia224aae1b8b4acd14ee09755387e3436c1dcdcbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2964216
Reviewed-by: Sebastien Lalancette <seblalancette@chromium.org>
Reviewed-by: sebsg <sebsg@chromium.org>
Commit-Queue: sebsg <sebsg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893077}
This CL creates a debug flag to help narrow down if the bug is due to
unintended user activation.
Android is the platform on which the issue is consistently reproducible,
so the plan is on Android canary:
1) Enable the flag and load the site.
2) Scroll without interacting with the site,
If the issue stops coming, it would confirm that there was a non-real
user activation that was being notified somehow which will need further
investigation.
Creating this change because the issue is not reproducible on
local builds.
Bug: 1201355
Change-Id: Ie6a57efbad4c6473419c555c1f00c3669d1b38c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2958836
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893073}
More flaky webgl conformance tests are observed on Mac FYI Retina
Release (AMD) bots. The crash log indicate we might try increasing
kGPUInfoWatchdogTimeoutMs for these build config.
Bug: 1220072
Change-Id: I1950092d934090e8f43ee5e59339e642dc3ed9eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2965602
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893071}
Adds instrumentation for kSmallAnimation/MediumAnimation PowerModes to
the frame sinks, breaking out animation use cases where only a small
(<= 3 sq inch) or medium area (<= 6 sq inch) is damaged.
Per-PowerMode UMA CPU time metrics will help us gauge the optimization
potential of such small/medium animations. For example, further down
the line, we could consider reducing the frame rate for these
animations to save power. Ultimately, this would be implemented in the
display compositor, but for the CPU time metrics, for now, this
instrumentation has to be local to the process performing the majority
of the rendering CPU work (i.e. in the renderer process).
Bug: 1166695
Bug: b:187693110
Change-Id: I58bbc1adee8099ee72359de20d0752f7bc3ed5eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2900232
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Sébastien Marchand <sebmarchand@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Auto-Submit: Eric Seckler <eseckler@chromium.org>
Commit-Queue: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893070}
I felt that the nested ifdefs were getting annoying to read and reason
about, especially considering that there was fallthrough and shared
logic in there. I split them out into OS-specific behavior since
I think it's a lot cleaner, even if it takes a few more lines. It's also
nice for anyone who's just touching one os's path (like I had to do in
the previous CL) to not have to reason about how the changes _might_
affect another OS.
R=liberato
Change-Id: I974c669f3e65af26772251ea656ccc4cdf596615
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2946789
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Ted Meyer <tmathmeyer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893068}
Add a builder function and a console for presubmit builders. Presubmit
builders are try builders that run quickly because they don't perform
compiles. Because they run quickly and because they tend to guard
against errors that would cause issues in the development process rather
than the chrome binaries, presubmit builders have the following
* Results from presubmit builders are not reused so that submitted code
will have them pass against somewhat recent code.
* Presubmit builders are run against all paths by default.
* Presubmit builders are run at a higher priority than most builders so
that //infra/config changes can be landed quickly to address outages.
properties:
Change-Id: I4b012e74dbd1d2fda9798b430efdae65c05d60d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2966613
Commit-Queue: Garrett Beaty <gbeaty@chromium.org>
Auto-Submit: Garrett Beaty <gbeaty@chromium.org>
Reviewed-by: Gary Tong <gatong@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893063}
