Texture quads are considered as "requires overlay" quads which means
that non-opaque occluded texture quads will be put into an overlay
without any possibility of blending. This is ok for video since overlay
compatible YUV video quads don't have any alpha, but texture quads can
have alpha. A totally transparent texture quad would show up as black.
This CL fixes that by applying the underlay validation check to texture
quads. Multiple texture quads are still promoted if possible, but a quad
could be skipped if it's occluded and non-opaque. This CL also adds a
pixel test for this scenario.
Bug: 1122638
Change-Id: I5c4f120d88ce8ad2bd340b7a4aa33d59fe1ef116
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2380161
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805096}
Adding a player to MediaSessionImpl automatically requests the audio
focus. We need to fix this up in case a paused player is added due to
entering Picture-in-Picture.
Bug: 1117390, 1117397
Change-Id: I1c8b69dbefe19f6d8a99a3b8d2a01fa2123a47f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2387643
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Commit-Queue: Wojciech Dzierżanowski <wdzierzanowski@opera.com>
Cr-Commit-Position: refs/heads/master@{#805056}
Before this CL, the child process start-up flow went like this:
1.) Browser would create a Mojo invitation, with a mojom::ChildProcess
receiver, that ChildThreadImpl would recover and bind.
2.) ChildThreadImpl immediately creates a remote for its
ChildProcessHost so it can start queueing messages for the browser
process, even though it is not bound to the browser.
3.) ChildThreadImpl asynchronously waits for ChildProcess::Initialize
to be invoked by the browser process; this supplies a remote for
mojom::ChildProcessHostBootstrap, which the child process uses to
send the receiver for the remote created in (1).
4.) Browser receives this, binding it to either
RenderProcessHostImpl::io_thread_host_impl_ or ChildProcessHostImpl
In short, there's an awkward dance that has to be done between the
browser <-> renderer ((3) above), so that they can both immediately
initialize remotes for each other. This CL removes the extra IPC round
trip by removing ChildProcessHostBootstrap, and steps (3) & (4) above.
This is done by attaching a second message pipe to the mojo invitation
corresponding to the ChildProcessHost receiver, so the child process has
it immediately on init. At this point, the child process can create a
remote for the ChildProcessHost, and immediately bind it to the pipe
which is bound to the browser process's ChildProcessHost receiver.
Bug: N/A
R=haraken@chromium.org,rockot@google.com
Change-Id: I8f7b4b698b82e25d1c5c991c9639e57de05a6360
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2393158
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Martin Barbella <mbarbella@chromium.org>
Reviewed-by: Tal Pressman <talp@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805037}
It was introduced in 724239 to inspect accessible trees by process id but this feature was removed in 1113674 as duplicate of inspect by window id feature
Bug: None
Change-Id: Ifec72d6ad2aef9238632588e8a65a77a37ca66d2
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2390852
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Alexander Surkov <asurkov@igalia.com>
Cr-Commit-Position: refs/heads/master@{#805036}
https://crrev.com/c/2353193 added a "kDragDrop" UserAction to be used when
accessing dropped entries via the native file system API. But somehow I
forgot to actually hook this up to the D&D code.
This hooks it up by adding a UserAction parameter to CreateFileEntryFromPath
and CreateDirectoryEntryFromPath (and simplifying some bits of code a bit).
Bug: 1124833
Change-Id: Ic8b165441996c64f2849fada1787a613adeee675
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2392772
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805034}
SkiaRenderer is strict about ensuring that the resource format passed in
to the display compositor via TransferableResource, which is used to
create the GrSurfaceProxy, matches the underlying SharedImageBacking's
format which is the GrSurfaceBackend.
In the context of DrawingBuffer this means that for low latency mode,
the ExternalCanvasResource must have the same format as the shared image
or swap chain. One problematic case is RGBA8 vs BGRA8 because the
default CanvasColorParams() used when creating the resource uses the
platform specific default for Skia, which is based on endianness, to
determine the format passed to the display compositor.
To solve this problem, this CL adds the shared image resource format to
ColorBuffer, and makes it the source of truth for all places that need
the format in DrawingBuffer. In particular, the CanvasColorParams is
constructed to match the underlying resource format instead of relying
on the defaults.
Bug: 1122638
Change-Id: I8c4e93d7f08566e695a3948505f98541d55b7216
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2391410
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805027}
This is a reland of d4c213d376
Original change's description:
> Remove INVALIDATE_TYPE_LOAD and INVALIDATE_TYPE_TAB on WebContentsImpl::LoadStateChanged()
>
> Since WebContentsImpl::DidStartLoading/DidStopLoading is already sending
> NotifyNavigationStateChanged(INVALIDATE_TYPE_LOAD) by way of
> LoadingStateChanged, it's no longer necessary to send this out in
> WebContentsImpl::LoadStateChanged. This change can reduce the number
> of call of TabStripModelObserver.TabChangedAt with TabChangeType.kAll
> a lot to increase performance throughout the browser
>
> Bug: 1112496
> Change-Id: I96d8942d7e1ebd5ffc8b3f3389497936f62848c7
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2357960
> Commit-Queue: Yuheng Huang <yuhengh@chromium.org>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#798852}
Bug: 1112496
Change-Id: I19b697d515cb56088a5dde836d51c7d5cf3c54b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2393155
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Yuheng Huang <yuhengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805007}
Currently AXPlatformNodeTextProviderWin::GetSelection() populates
selection SAFEARRAY as nullptr if the selection is a degenerate range on
a non editable node. Hence correct selection range is not returned on
deselecting the selected character.
This CL adds the change to return a valid selection for a degenerate
range. It also adds the conditions in
AXPlatformNodeTextRangeProviderWin::Select() to prevent selections
inside of a list marker. Relevant unit tests are added to validate the
change.
AX-Relnotes: Fixed an issue with character selection for Narrator users.
Bug: 1114779
Change-Id: I882ca2c6ade013678b948548918b02417d85aee6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2346095
Commit-Queue: Kurt Catti-Schmidt <kschmi@microsoft.com>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#804982}
This test verifies that the candidate SiteInstance is not used for a
cross origin redirect, that would lead to have a SiteInstance hosting
a crossOriginIsolated page with an incorrect top level origin as
initially registered.
Bug: 1107814
Change-Id: If52fef13528ca8d2f8dcf8af04b6510462072f43
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2396379
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804894}
If the xr-spatial-tracking feature policy is disabled, throw a
SecurityError on makeXRCompatible. This is to prevent an unnecessary
restart of the GPU process.
The WebXR spec isn't clear on the behavior when the xrCompatible flag
is set when requesting a context. In this scenario, this change simply
sets the flag to false without throwing an exception.
The WebXR spec has also been updated to specify that an
InvalidStateError should be thrown if there are no devices available.
The kNotCompatible enum is split into specific reasons for why we
can't be XR compatible to be able to throw the corresponding exception.
A subsequent change will add a blink feature for multi-GPU and add
corresponding tests
Bug: 1124024
Change-Id: I5207ed56d838d76eedf2287f0bd6e1fffd2c5b95
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2388902
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Patrick To <patrto@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#804891}
WebContentsImpl is a major class responsible for routing many events
between different parts of //content and between //content and the rest
of the codebase (e.g. //chrome and //components).
Add trace events to all non-trivial methods to ensure that it's possible
to understand the execution flow from reading the trace.
Together with crrev.com/2343269 this in particular would allow the
user of the tracing to know which WebContentsObserver notifications were
dispatched.
R=nasko@chromium.org
BUG=1043616
Change-Id: If00550c233ab16186a2ebf9f4042c5f1fd457fdd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2240326
Commit-Queue: Alexander Timin <altimin@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804869}
The equality of the "cross origin isolated" value should not be checked
if it's still speculative, and some other cases covered by
IsSiteInstanceCompatibleWithCoopCoepCrossOriginIsolation.
Bug: 1107814, 1096135
Change-Id: I37152bbc348d598dc4612666bfc181da60e75555
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2385255
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804854}
EditingNG has some instabilities such as <crbug.com/1121885>.
In order to help users who turn on "Experimental Web Platform
features" from hitting these issues, this patch changes
EditingNG back from "experimental" to "test".
Once ourstanding issues were resolved, we will change it back
to "experimental".
This is a revert of r791809 <crrev.com/c/2319947>. Some
rebaselines are needed because these tests do not seem to
honor "test" status.
Bug: 707656, 1125477
Change-Id: I433200cb7fb450036a631ee8ed578ab395413540
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2390936
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804839}
Currently, content::IsOriginSecure() util is used by
ResourceDispatcher, which will be removed along with OnionSoup.
This patch moves content::IsOriginSecure() into Blink, so that we
could onion-soupify the ResourceDispatcher.
Change-Id: I7b9975ccc50bb28e13c37107588c9e071450f39f
Bug: 1110032
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2392044
Commit-Queue: Minggang Wang <minggang.wang@intel.com>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804829}
Along with the OnionSoup for loading, we will have more utils
needed to be moved into Blink.
This patch puts these utils defined in network_utils.h/cc into
namespace blink::network_utils to avoid contaminating
namespace blink.
Bug: 860403
Change-Id: I1b9de8ece4427e70a9897a95898efd2e6b10c7d8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2392632
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Minggang Wang <minggang.wang@intel.com>
Cr-Commit-Position: refs/heads/master@{#804760}
This CL migrates these two legacy IPC messages out of view_messages.h
to the {Local,Remote}MainFrameHost mojo interfaces from Blink, by using
the newly defined method UpdateTargetURL() in both interfaces (required
to work both when the main frame in the renderer is local or remote).
Additionally, this CL moves the UpdateTargetURL() method present in
RenderViewHostDelegate into RenderFrameHostDelegate, now that the IPC
message will be now received in the browser process by a RenderFrame,
instead of being handled by RenderViewHost as it was the case before.
Last, the UpdateTargetURLWithInvalidURL unit test has been moved out of
RenderViewBrowserTest and into WebViewTest, as that reflects better the
situation in the renderer side now, and also to get friend access to
the |target_url_| private attribute, which is now part of WebViewImpl.
Bug: 993189, 1047464
Change-Id: Ib97ee5270221efc48d50138cf3f075619430d063
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2387801
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Mario Sanchez Prada <mario@igalia.com>
Cr-Commit-Position: refs/heads/master@{#804735}
This CL removes ServiceWorkerMetrics dependency from
ServiceWorkerStorage by embedding UMA recordings into it.
ServiceWorkerStorage will be moved to //components/services/storage
but ServiceWorkerMetrics will remain //content. This means that
ServiceWorkerStorage cannot use ServiceWorkerMetrics.
This CL also applies histogram guidelines
(//tools/metrics/histograms/README.md).
Bug: 1016064
Change-Id: I79ba99c096fc422166b0f0f23d27728804701113
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2394899
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804710}
This change removes all calls from NavigationSimulatorImpl to
NavigationRequest::set_response_headers_from_testing. Those calls are
not needed anymore, since https://crrev.com/c/2294801 added a method
NavigationSimulator::SetResponseHeaders which allows to mock response
headers going through the URLLoader.
The function NavigationSimulator::FailWithResponseHeaders, which was
relying on NavigationRequest::set_response_headers_from_testing, turn
out not to be needed anymore and has been removed in this CL.
Change-Id: I7ab18e0c2306aab97f4d04ad655fec5aa050f43c
Bug: 1094909
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2310416
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Tim Schumann <tschumann@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804701}
This state shadows states from the RenderWidgetHostImpl and we can
just rely on that.
Then, RenderWidgetHostViewBase no longer needs to act as an observer of
RenderFrameMetadata submissions. The platform specific implementations
do, but they can each do so on their own. This avoids multiple levels of
implementations of this interface.
While we're at it, RenderWidgetHostViews should always be destroyed by
calling Destroy(), so we make the destructors protected and fix up some
code that relied on them being public.
R=avi@chromium.org
Change-Id: I45ee67c7e3fa73a33ba6d8dc83071a75baa2b2ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2392622
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804617}
crrev.com/c/2259537 made ChromeWebUINavigationBrowserTest use
RenderFrameHostImpl directly for testing instead of using the
existing content::PwnMessageHelper::OpenURL(). But, it's a layer
violation. So this CL restores OpenURL() in content::PwnMessageHelper
in browser_test_utils.h again, then makes it use
content::PwnMessageHelper::OpenURL() to fix the layer violation.
Additionally, all test methods of PwnMessageHelper start to use
Mojo methods instead of IPC method. So, this CL updates the comments
properly.
Bug: 1093920
Change-Id: I8608cb7bc5a3e84628c741020ed2515d28445e2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2387541
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Cr-Commit-Position: refs/heads/master@{#804591}
The referrer policy is only used when dragging a link out of the WebView
results in a download. This is handled on Windows when the mime type is
'downloadurl'. This CL avoids storing the policy unconditionally when
converting the DragData Mojo type to DropData.
Bug: 1039255
Change-Id: Id0b94a7bddb274b53aba2e5c163407f0c875d95c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2391068
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Henrique Ferreiro <hferreiro@igalia.com>
Cr-Commit-Position: refs/heads/master@{#804573}
AXPosition::AtEndOfTextSpan relies on CreateParentPosition to
determine if an inline text box marks the end of text span. Since
CreateParentPosition calls into AtStartOfLine which calls
AtEndOfTextSpan so we end up with an infinite loop and stack overflow.
https://crrev.com/c/2245611 fixed most cases with this infinite loop
of AtStartOfLine/CreateParentPosition/AtEndOfTextSpan by checking for
AtEndOfAnchor first before calling AtEndOfTextSpan.
However consider the following example:
<style>
.required-label::after {
content: " *";
}
</style>
<label class="required-label">Required </label>
labelText #1
++staticText name='Required ' nextOnLineId=inlineTextBox #2
++++inlineTextBox name='Required ' nextOnLineId=inlineTextBox #3
++staticText name=' *' previousOnLineId=inlineTextBox #4
++++inlineTextBox name='*' previousOnLineId=inlineTextBox #5
AtEndOfAnchor check would not prevent this infinite loop, if
AtStartOfLine is called on staticText #4 name=' *' as the max text
offsets differ between staticText #4 and its inlineText #5.
This CL fixes the above issue by making AtEndOfTextSpan not to call
CreateParentPosition. Instead it determines end of text span by
directly looking at the current position's parent role and its index
among its siblings.
AX-Relnotes: Fixes hangs in certain accessibility scenarios.
Bug: 1120636
Change-Id: Ic99c27b069f220f26da736b3946560ef23d6b622
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2369681
Commit-Queue: Victor Fei <vicfei@microsoft.com>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804531}
The ui_utils_java target is not a suitable place for this code because
it needs to use WindowAndroid instead of Context (for WebLayer's sake),
and ui_utils_java can't depend on WindowAndroid.
This glue code is moved to org.chromium.content_public.browser.
Bug: 1117536,1016938
Change-Id: Ic18275e2f0eca0739b850418af6c71d2079c6da5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2380343
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804505}
This CL adds a lookalike navigation browser test for signed exchanges.
The current lookalikes code blocks signed exchanges in both of the
following cases:
- The target URL of the SGX package is a lookalike
- The URL that serves the SGX is a lookalike
For the first case, the test navigates to a signed exchange URL that
serves a SGX for google-com.example.org and checks that the URL is
blocked by the target embedding heuristic. The second case serves the
SGX from google-com.example.org and checks that it's blocked.
There is an argument to be made for the latter case to not be blocked
since the URL that serves the SGX is never seen by the user during
normal browsing such as clicking links. However, there is still a chance
that such a URL is shared from outside Chrome (e.g. coming in an email).
We still want to block those cases.
Additionally, detecting that a navigation will end up as a SGX isn't
trivial as the SGX package needs to be fully validated before its
contents can be displayed. It might be too late to block the original
navigation by the time the SGX is validated. This needs to be confirmed
and might be changed in follow up CLs.
Bug: 1110151
Change-Id: I2b2e4841eb142b3f2d1c1cedf82138f578e770a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2386429
Commit-Queue: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: Joe DeBlasio <jdeblasio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#804412}
